Discussion:
A good idea?
(too old to reply)
B Bruen
2014-09-20 22:24:07 UTC
Permalink
As some will know, we use a lot of third-party (i.e. developed by us) components and libraries in our projects.
Some of these are re-usable pop-up forms to provide common features across our gui apps. Things like "AboutMe" and "SysInfos" forms that we need to place in all our client applications.

Each of these requires that we include the component in the project properties, create a menu item in the relevant form and an event handler for that menu item. All these handlers essentially do is create an instance of the pop-up and ShowModal it.

The other day I had an idea. I created a virtual control "wrapper" class that takes care of the above by itself. All the coder need do is to place the virtual control on the relevant form in form design mode.

Anyway, this seems to work! I cant see any problems and I am now looking at more complex uses of this approach. Perhaps it might be a way to implement the IDE add-ins mentioned recently?

Here is a project that mocks up this approach in that it is totally self contained (i.e. doesn't use components or libraries). If you would take a look you'll see that the main form, i.e. the "client", has no code at all for managing the pop-up (but does have a handler for an event raised by the pop-up).

What do you think?

regards
Bruce
--
B Bruen <***@paddys-hill.net>
Tobias Boege
2014-09-20 22:57:55 UTC
Permalink
Post by B Bruen
As some will know, we use a lot of third-party (i.e. developed by us) components and libraries in our projects.
Some of these are re-usable pop-up forms to provide common features across our gui apps. Things like "AboutMe" and "SysInfos" forms that we need to place in all our client applications.
Each of these requires that we include the component in the project properties, create a menu item in the relevant form and an event handler for that menu item. All these handlers essentially do is create an instance of the pop-up and ShowModal it.
The other day I had an idea. I created a virtual control "wrapper" class that takes care of the above by itself. All the coder need do is to place the virtual control on the relevant form in form design mode.
Anyway, this seems to work! I cant see any problems and I am now looking at more complex uses of this approach. Perhaps it might be a way to implement the IDE add-ins mentioned recently?
Here is a project that mocks up this approach in that it is totally self contained (i.e. doesn't use components or libraries). If you would take a look you'll see that the main form, i.e. the "client", has no code at all for managing the pop-up (but does have a handler for an event raised by the pop-up).
What do you think?
Veeeery nice idea! It looks a bit like an hack, though, because it's not
obvious (from the IDE form editor or otherwise) what the virtual control
does. I like it anyway.

I think you could even have a "MenuMaker" class which is your VControl.class
minus the menu-specific things. You would derive "HelpMaker" from that class
which provides the necessary names, like "mnuHelp", etc. and a real MakeMenu
method (or event handler?).

For the others: there is an error "Component not found: genutil". You can
either fix this yourselves or apply the attached patch. It seemed to be safe
to just remove that component (?).

Regards,
Tobi
--
"There's an old saying: Don't change anything... ever!" -- Mr. Monk
B Bruen
2014-09-20 23:18:27 UTC
Permalink
On Sun, 21 Sep 2014 00:57:55 +0200
Post by Tobias Boege
Post by B Bruen
As some will know, we use a lot of third-party (i.e. developed by us) components and libraries in our projects.
Some of these are re-usable pop-up forms to provide common features across our gui apps. Things like "AboutMe" and "SysInfos" forms that we need to place in all our client applications.
Each of these requires that we include the component in the project properties, create a menu item in the relevant form and an event handler for that menu item. All these handlers essentially do is create an instance of the pop-up and ShowModal it.
The other day I had an idea. I created a virtual control "wrapper" class that takes care of the above by itself. All the coder need do is to place the virtual control on the relevant form in form design mode.
Anyway, this seems to work! I cant see any problems and I am now looking at more complex uses of this approach. Perhaps it might be a way to implement the IDE add-ins mentioned recently?
Here is a project that mocks up this approach in that it is totally self contained (i.e. doesn't use components or libraries). If you would take a look you'll see that the main form, i.e. the "client", has no code at all for managing the pop-up (but does have a handler for an event raised by the pop-up).
What do you think?
Veeeery nice idea! It looks a bit like an hack, though, because it's not
obvious (from the IDE form editor or otherwise) what the virtual control
does. I like it anyway.
Very much a hack at the moment! In fact more of a proof of concept at this stage.
Post by Tobias Boege
I think you could even have a "MenuMaker" class which is your VControl.class
minus the menu-specific things. You would derive "HelpMaker" from that class
which provides the necessary names, like "mnuHelp", etc. and a real MakeMenu
method (or event handler?).
Yes, that's what I was alluding to as the "more complex" matters.
Post by Tobias Boege
For the others: there is an error "Component not found: genutil". You can
either fix this yourselves or apply the attached patch. It seemed to be safe
to just remove that component (?).
Regards,
Tobi
--
"There's an old saying: Don't change anything... ever!" -- Mr. Monk
Oops! I just stuck that GenUtil reference in to get at the help for it while responding to another thread. It is immaterial to this thread - so yes just remove it.

Thanks for the feedback.
B
--
B Bruen <***@paddys-hill.net>
B Bruen
2014-10-11 22:11:14 UTC
Permalink
Just an update.

This works really well. Thanks Tobi for help in crystallising where I was trying to go with this.
So far (I am only working on this part-time - it's a non-income earner but it will save so much time and effort in the future) I have a robust solution for fully-autonomous pop-ups (ones that are fully independent of the application project e.g. "System Information") and quasi-autonomous popups (ones that get information on the application project out of the executable archive e.g. "About Me"). Converting our existing popup components into virtual menu items now takes only a few minutes per component - add a wrapper class that inherits the VMenuItem class, set a few properties, compile and install.
I am now working on the best way to handle popup forms that rely on or interact with the dynamic data in the application project. Say a general "EditClient" popup that would be made available in "OrderEntry" or "Invoice" application projects where I want to pass the current Client object to the editor popup and have the application client's object automatically update and refresh when the popup is "Saved". I have a couple of prototypes of different ways to handle this and a few more ideas. Will decide on the best way after a bit more work.
Should this work (or when it works) opens up this concept to a wider approach that not only handles what I am now calling "virtual menu items" but also "virtual toolbuttons", and other virtual controls (in the above examplpe, think of a client name buttonbox that handles the entire edit processing within itself, no code needed in the application project).

Another idea is to use this approach to provide entire "standard" menus by dragging a virtual control onto a form. This would include, say, File|Edit|View|Tools|Help and all the associated submenus. Just drag the VStandardMenu virtual control onto the form - no need to build these menus via the IDE each time....

rgrds
Bruce
--
B Bruen <***@paddys-hill.net>
B Bruen
2014-11-29 22:01:33 UTC
Permalink
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 <***@gmail.com>
B Bruen
2014-11-29 22:25:49 UTC
Permalink
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 <***@gmail.com>
Jack
2014-09-21 06:59:28 UTC
Permalink
Post by Tobias Boege
For the others: there is an error "Component not found: genutil". You can
either fix this yourselves or apply the attached patch. It seemed to be safe
to just remove that component (?).
Or recompile the project
--
Cordialement

Jacky Tripoteau
Loading...