Re: [Gambas-user] A good idea? Revisited again.
So far, and ignoring our own industry specific (see Note 1) virtual menu items, I have produced the following general popup forms as virtual menu items (custom controls): * Help|About Me : A virtual custom control that implements a standard popup form showing information about the current application extracted from the Gambas executable archive. * Help|System Information : A virtual custom control that implements a standard popup showing information about the current OS, Gambas and application environment. * Help|Browse Help : A virtual custom control that provides an application level help browser similar to the IDE help browser. This is supported by a help system development utility. However it has some limitations as explained in Note 2 below. * File|Recent : (This one I am very happy with :-) ). A completely self contained implementation of the Recent Files concept. *File|* : This one is a bit weird, it creates a standard File menu item at the top level and most (well OK some) of the standard things one would expect in the File menu of a normal user application. See Note 3. *Tools|Options : (On the one hand I'm very happy with this, on the other...) A virtual custom control that implements a program options menu item under Tools and a popup form similar to the IDE Tools|Preferences menu item. It creates the entire popup form on the fly from a definition file (let's call it .options) within the executable archive. The other hand is this. I have hacked the IDE form designer code a bit and can now edit that definition file from within the IDE. That is, the virtual control component has a form that let's the programmer create/modify the definition file. The IDE hack responds to a button click on the Options property, shows the editor (which is somewhat similar to the Menu editor) and allows the programmer to set up the Tools|Options for the project without a single line of code. I am not really very happy with the way the hack works (Note 4) but it does appear to work. What's the point of all this? -- These custom controls provide self contained functionality that implement a menu item in a form menu by simply dragging the control from the toolbox onto the form. Little or no coding is needed in the form class to manage that functionality. For developers who support multiple projects and would like to have the same functionality, with the same appearance, shortcut key etc etc across multiple forms this approach makes implementing that standard-ness very easy. I would like to know whether there is any interest in this stuff. We are quite prepared to publish them on the Gambas farm if there is such interest (they are programming tools if you like and thus have no commercial value to us.) regards Bruce -- B Bruen adamn...@gmail.com -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
Re: [Gambas-user] A good idea? Revisited again.
Woops, I chopped off the notes. Notes 1] This concept can also provide with minimal effort your own industry specific virtual menu items. For example, say your system has a EditCustomer form that you want to be able to access from mulitple other forms in your system. By wrapping that form in a virtual menu project, which takes but a few minutes, you can create a virtual custom control for the form. 2] The helpset development utility is buggy and there is a problem with relative paths that I haven't got around yet (complex situation where the target helpset file is in a middle level component, i.e. application project uses vhelp component and another vmenu component, say a search utility which also uses vhelp. I cannot solve how to extract the target help set file from the middle component ... 3] alpha only 4] This is an interesting thing, I have a patch/hack for the IDE that lets us run the custom control configuration editor. It is a fairly simple change to FProperty.class around line 774: --- FProperty.class(revision 6688) +++ FProperty.class(working copy) @@ -774,8 +774,15 @@ Case Else 'object - hEditor = cmbProperty - InitComboWith($hForm.FindControlFromType($sType).Sort(gb.Natural + gb.IgnoreCase), ( (None) )) + If $hObject.Unknown Then +If Project.Sources.Exist(FEditConfig.form) Then + Project.Run(False, -1, FEditConfig) + Return +Endif + Else +hEditor = cmbProperty +InitComboWith($hForm.FindControlFromType($sType).Sort(gb.Natural + gb.IgnoreCase), ( (None) )) + Endif End Select It looks for a specifically named form in the current project and if found then runs that form. The configuration must be self contained, i.e. in this case we write an options text file into the source project directory. It cannot send any information back to the IDE. Not entirely satisfactory but it does provide some sort of proof that it may be possible to enhance the IDE properties editor through external code. regards Bruce -- B Bruen adamn...@gmail.com -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk ___ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
