It might be possible to dynamically create the user interface if the
window contains a control array for each type of control that would be
needed.
Once you have a control array you can create instances of the controls
at runtime.
We do something similar to display a read-only form that shows dynamic
meta-data stored in a database.
HTH
Kev
On 31 Dec 2008, at 05:10, "Eric Williams" <eric@oxalyn.com> wrote:
>
> On Dec 30, 2008, at 2:05 AM, Tom Benson wrote:
>
>> This is going to sound strange from a long time RB user, but I've
>> been out of the loop for a while on Web based projects, so here
>> goes anyway.
>>
>> Oversimplified Scenario:
>>
>> Imagine (simply) a listbox that lists all of the installed plugins
>> in the apps "plugins" folder, with a folderitem reference to each
>> plugin stored in the celltag property. Easy enough.
>> Then imagine that to the right of that listbox is an empty area
>> that I would like to embed a containerControl instance in.
>> Which containerControl instance I embed depends on which plugin
>> from the list I select, and the instance should be loaded from that
>> plugin file/binary.
>
> No way to do this, unless you're going to create the controls
> yourself (i.e., the plugin contains a description of what the user
> interface, and you create one during runtime based on the
> description). RB does not support loading user interface elements
> like this; they must exist in the compiled binary to appear on the
> screen.
>
>> I'm guess what I'm asking is "Is it possible to create an
>> application that can be functionally extended by plugins (created
>> in REALbasic), similar in concept to photoshop, OS X mail etc.?"
>
> Yes, but the user interface is the hard part. I built an entire
> plugin system a number of years ago, but I don't think it's probably
> flexible enough or fast enough for most needs. Essentially, each
> plugin was an AppleScript, an internal class, or an external compiled
> application that communicated with the host application via a simple
> string interface. My plugin-enabled apps would have a list of
> plugins, similar to what you're describing, but would only present a
> user interface when the user pressed an "Edit Settings..." button,
> and then the plugin settings would be presented in a modal dialog. If
> you've ever used FileMaker, it's set up similar to some of
> ScriptMaker circa 2001. :)
>
> The principles are close to what you're talking about, but my
> implementation was rather limited. Plugins could only be explicitly
> called by the application; they couldn't wait around for things to
> happen and take action on their own. They were limited in that they
> had little access to the application's internal data structures (with
> the exception of the compiled-in plugin classes).
>
> Here's a wild though. How about if your plugins presented a user
> interface via HTML? Your app could query them for an HTML interface,
> run it in HTML Viewer, and feed the result back to the plugin. This
> would allow each plugin to present a very rich interface without
> binding all the controls to RB code (of course, they would have to
> programmed in JavaScript or something similar).
>
> Eric Williams
> Oxalyn Software
> http://software.oxalyn.com/
>
> AE Monitor
> http://software.oxalyn.com/AEMonitor/
>
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|