Diese Seite mit anderen teilen ...

Informationen zum Thema:
WinDev Forum
Beiträge im Thema:
Erster Beitrag:
vor 2 Jahren
Letzter Beitrag:
vor 2 Jahren
Beteiligte Autoren:
GuenterP, DerekT, Piet van Zanten, Sascha77, CCC2, steve erts, Ned!, Steve Hodgman

Project using Internal Windows

Startbeitrag von GuenterP am 27.01.2016 08:02

Hi all,

has anyone developed a fine system which uses internal windows in a main window instead of stacking windows on top each other like in SDI or MDI?


Hi Guenter,

i am using Internal Windows in combination with a Dynamic TabControl. Works quite well for me.


von Sascha77 - am 27.01.2016 11:00
Hi Guenter,

I have a project that uses a main window and there are currently 60 internal windows within that.

I still use popup windows to add/update records and I need to add something to stop the data in the internal windows being loaded when the main window opens, but it works ok with no problems.


von Ned! - am 27.01.2016 11:45

I have got what might appear the worst of all worlds although to be fair I am using it as a bit of a play around.

I have an MDIMain with 6 MDIChildren
Each of the MDIChild windows use multiple internal windows.

To avoid 'flickering' when changing from one IW to another every one is displayed in its own Internal Window Control with each of these being on its own plane and controlled from 1 or more ribbons which of course have themselves got multiple buttons.

And to top all this I am using the MVP RAD, which is the main reason that I am using IW's owing to how the classes are structured and used.
Now I am getting into MVP a bit it is not quite as bad as it might sound and actually functions very well.

Basic concept is that each internal window always has 3 procedures....
lpAdd - Calls to the popup (modal) window for create
lpUpdate - Calls to the popup (modal) window for modify
Processing in both is pretty similar to handle not only its own display requirements but also any that may be required on the parent (calling) window.
lpRefresh - Updates the display (table or form) records if a changes need to be shown.
Used mainly when tabbing through the ribbon control and testing if the IWC has already been populated - use this if it has, again avoids the 'flickering'

And finally I do have a couple of IW's that use a Tab controls which in turn, you guessed it, use an IW on each tab.
Bit trickier but as long as you keep track of where you are, no real issues.

If you are contemplating going down the IW route then I can see no reason for you not doing so.
What you will need is a clear head, a stack of paper and plenty of sharp pencils.

von DerekT - am 27.01.2016 13:08
Thanks a lot to all of you!

I'm planning to make a new program using internal windows based on a currently sold product which comprises ~170 MDI windows which fit neatly in their parent's frame. I do not plan to iclude any modal windows but instead to use planes of the internal windows. I have to find a reliable mechanism to stop users from opening another internal window from the main menue while another internal window is being edited. Next, since there are no previous windows, a mechanism has to save the content of a window when another one has to be opened, let's say an invoice is being prepared and a new item has to be input into the items file, a changed customer address, a new price etc. Looks for me like I have to create many windows / planes with exactly the same edit controls, tables etc on them since there's no economical way to store the contents of a window or the the status of a window? I'd love to stick with the proven MDI concept but this will not work in Java, Linux or a Windows store app.

von GuenterP - am 27.01.2016 16:01

Sounds like a lot of internal window my friend:rolleyes:

With regard to to 'saving the content' in your example....
As long as the 'IW_Invioce' and 'IW_Items' are opened in their own Internal Window Control and they occupy different planes on IW or even the main window then any values entered for the invoice will not be lost.
You just need to remember which plane to return to following your 'item' addition and as both IW's will be open the new value added can easily be inserted into the invoice as part of the 'Save' operation.

Treating 'update/create' IW's as modal can only be achieved by setting a flag(s) and testing this on each call to ChangeSourceWindow().
Did this a while back - it does get a bit complex, now gone back to popup modals for this type of operation.

von DerekT - am 27.01.2016 16:29
I'm not using as you describe but I do use a lot of internal windows. It is a fabulous feature. For instance I have an internal window for managing email communications and this is available from wherever email is needed in my software (Clients, Bookings, Vendors etc..)

I also have a task management feature that is implemented in the same way.

von steve erts - am 27.01.2016 17:29

With regard to to 'saving the content' in your example....
As long as the 'IW_Invioce' and 'IW_Items' are opened in their own Internal Window Control and they occupy different planes on IW or even the main window then any values entered for the invoice will not be lost.

Hi Derek, of course, but this means that I'd have to provide several internal planes / windows - all of them containing the same controls as an input sequence. e.g. for an item or a customer. Otherwise I'd have to somehow "remember" what's been done up to now on that unfinished window for an invoice , a delivery slip .. whatever. This will force me to have duplicate planes (including all of the necessary procedures) on many of those internal windows. Makes me think of making a general procedure which identifies all of the controls and puts their eventual contents into a comma separated string and anopther one which restores the contents of the controls when coming back. Smells very complex and error-prone to me .. thank you!

von GuenterP - am 27.01.2016 18:18

Maybe I have got hold of the wrong end of the stick (not for the first time) but this is what I thought you meant - indeed what I often do......

IW_InvoiceEntry is displayed on Main..Plane = 2 in IWC_Invoice and contains 20 controls.

Control 5 is a combo to which I need to add a value.
The window I use to do this is on Main..Plane = 15 in its own IWC_ComboAdd
You could of could have it on a different plane of IW_InvoiceEntry but then it would only be available for this activity.

On completion of the addition I return to Main..Plane = 2 were of course IW_InvoiceEntry still contains all the previously entered information.
Also prior to returning to Main..Plane = 2 I would have run my IW_InvoiceEntry.lpRefresh procedure (both IW's are active) to repopulate the combo and select the record I had just entered.

Does not matter whether IWC_ComboAdd is on IW_InvoiceEntry or the main window the principle is the same.

What you will need to do IMHO is use a separate IW/IWC combinations.
If you use the same IWC the a. you lose any data entered and b. you will get a ghastly flickering effect as the display changes.

If I have not understood your intentions, apologies.
But you never know it may come in useful.

von DerekT - am 27.01.2016 18:48
Hi Derek,

thank you! That's a good idea! I could have the main window with several planes and on each of these planes an internal window control ! Which means that I could for example have the item input without destroying the invoicing window - it's just a question of switching planes! Not so much a switching of planes of the internal windows but of the main window! Thanks, you gave me a kick in the right direction!

von GuenterP - am 27.01.2016 21:17
I have chosen to do the majority of my current development using all internal windows. Well, there is a WIN_ProjectName as a base and one general purpose modal WIN_Dialog called multiple times as needed.

Both the WIN_ProjectName and WIN_Dialog have a Navigationsection and an IWC_Empty for the rest of the screen. Each window has generic code for dealing with its function also.

Each of my Internal Windows (e.g. IW_Display) has associated with it a IW_Display_Class and a VM_Display Class

The IW_Class defines the navigation/CRUD controls, methods, properties etc for the associated IW display. At runtime, this instantiates the navigation controls defined in the class. These controls are placed in the Navigation area of the screen. The "click" code calls procedures of the IW_Display.

The VM_Class has all the DataView elements used by the IW Display. This is where the database is accessed and updated.

The IW_Display contains all the controls needed and these are linked to properties of the VM_Class. Procedures of the Internal window do all of the screen view" operations on the data (e.g. Validate, Open New Window, SaveData). Data operations a executed by properties and methods of the VM_Class.

My development is structured into Internal components, each sorted into "functional areas" so that a new project simply has to include an existing internal component in order to include the associated IW displays for that functional area.

The above is an attempt at giving an outline of what I have done. I am still in V19 and have not yet sampled the PCSoft attempt at incorporating a VM. It would be fantastic if PCSoft would allow us to generate Classes (properties, methods) in code! Currently, creatign base data classes is laborious but worthwhile in the long run. Overall it has been a good development paradigm providing a good standardised way of integrating disparate screens in ways that I had not envisaged. Currently I have Eight applications in operation based on my components.

I have not used planes to the extent that you are describing. I use them sometimes but eventually I find that it gets confusing in the IDE navigating the layers and controls. But, maybe I am missing something in my technique.

I definitely recommend using Internal windows. They provide a reasonably simple way to create an application with infinitely reusable components.
Good Luck,
Steve H.

von Steve Hodgman - am 28.01.2016 02:48
Hi Guenter,

Don't you use modal windows for editing?
For the display window you use an internal window with all fields in display only mode and in the edit window you use it in edit state.


von Piet van Zanten - am 28.01.2016 22:43
Hi Guenter,

I am using 2 Dynamic Tab Controles. The main Tab Control opens a Module like "Invoices Overview" as an internal window. This internal window itself has another tab control which allows me to open as many Invoices I want to work with in parallel.

With this approach i do allow the user to toggle between open modules and detail screens.


von Sascha77 - am 29.01.2016 04:51

Re: Project using Internal Windows - DEMO project -

Hi Piet, no, the plan is to use internal windows for everything, only messages (info(..), error(...) ...) will be "modal".

I already made a multi-windowing demo project as a starter in order to duplicate MDI behaviour ... a second demo project will follow showing the use of a RAD11-like HFSQL project. Stay tuned!


von GuenterP - am 29.01.2016 05:29
Hi Sascha, the problem is that the new dynamic Tab control is for Windows only! The idea was to convert the Windows project to a Java, Linux and Windows app more easily. Maybe, we will see the dynamic Tab control in future versions in other environments too, but there's no PCS commitment to that.

von GuenterP - am 29.01.2016 05:35

Re: Project using Internal Windows - DEMO project -

Hi Guenter,

I've been on that road, but disabling all kind of stuff while in edit mode was too much of a hassle.
Modal windows do it all automatically, so I really don't see any advantages of doing everything in one window.


von Piet van Zanten - am 29.01.2016 08:37
Hi Guenter ,

I don't use IW that much in windev program .

I created before a similar layout of program like Guenter test program using VisualStudio (vb.net) . but unlike VS , windev internal window variable become part of main window , not independent . if you try to create 2 IW and inside you declare same name variable . Wx will throw warning.

in VisualStudio you can create instance of a window and attach into a tab control. while doing that the variable in the window can be public / private .

if you don't use alot variable in the program , then use IW should be ok else good luck with come out unique name for the variable for each IW

von CCC2 - am 29.01.2016 09:28
Zur Information:
MySnip.de hat keinen Einfluss auf die Inhalte der Beiträge. Bitte kontaktieren Sie den Administrator des Forums bei Problemen oder Löschforderungen über die Kontaktseite.
Falls die Kontaktaufnahme mit dem Administrator des Forums fehlschlägt, kontaktieren Sie uns bitte über die in unserem Impressum angegebenen Daten.