October 06, 2022, 11:46:39 AM


Own IWBasic 2.x ? -----> Get your free upgrade to 3.x now.........

7a Adding Controls

Started by LarryMc, October 18, 2014, 09:32:01 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


In the previous section I posed the question of whether or not I had placed some code in the wrong location based on the discussions in the previous sections.

There have only been a few that have downloaded the source code and none has commented so far.
It is the weekend  but I didn't feel like waiting till next week to see if anyone commented.

So I'm pressing on.

In section 6. Constants, we added some controls to the main window (w1).  As part of adding them we put their constant IDs in the globals.iwb file in the constants section.  We put them in that section so they would be Project global and could be addressed from any source file in our project.

When we added the controls for the dialog (dlg1) we didn't put them in the globals.iwb file in the constants section.  Instead we put them in the dialog1.iwb file which makes them source file global but not Project global.

What we were wanting people to notice and question was why didn't we put the dialog's control ids in the same location as the main window's control ids.

The main window is always open while our project is running.  And, for numerous reasons a child window, child dialog, or subroutine may need to read from or write to one of the main window controls.  For the same reasons, the main window's menu ids and the main window's toolbar and it's buttons need to be treated the same as the main window's control ids; that is, the ids should be made Project global by placing them in globals.iwb file in the constants section.

So, why didn't we make the dialog control ids Project global?

As mentioned in a previous section dialogs don't really exist until we show them with SHOWDIALOG or DOMODAL.
And when you get down to it we should only use SHOWDIALOG when the main form of the application is a DIALOG.
Otherwise, if the dialog is a child of either a window or a dialog we want to open a child dialog with DOMODAL.

This results in the question: "Why do we have to use DOMODAL when opening a child dialog?"
When DOMODAL is used it automatically disables the main window/dialog.  By doing so, multiple instances of the same dialog can not be opened from the main window/dialog at the same time.  If SHOWDIALOG is used than multiple instances of the dialog can be opened(along with other dialogs of the same parent).  When we do this we usually wind up having to close our application in order to get all the dialogs closed.

The answer to our question:

Before a dialog is opened with DOMODAL we can not access any of its controls so that's one reason not to make its control ids project global.

In the case of our tutorial examples we have not created a child dialog of dialog dlg1 therefore that is another reason not to make dlg1's control ids project global. if dlg1 called a child dialog then we would have added dlg1's control ids to the globals.iwb file.

If any of our subroutines(yet to be added) are called by dlg1 and the results need to update one dlg1's controls we simply have the subroutine return the value to dlg1 and have dlg1 place the value in the proper control.

Keep in mind, one of our ultimate goals is to make information Project global that really needs to be made project global while making our code as modular as possible so we don't have to look at any code we have finalized.  That's why each of our child dialogs will basically be self contained in their own source file.

This completes 7a Adding Controls
Larry McCaughn :)
Author of IWB+, Custom Button Designer library, Custom Chart Designer library, Snippet Manager, IWGrid control library, LM_Image control library