|
FOROS PROFESIONALES
WINDEV, WEBDEV y WINDEV Mobile |
| | | | | |
| Project using Internal Windows |
| Iniciado por guest, 27,ene. 2016 09:02 - 16 respuestas |
| |
| | | |
|
| |
| Publicado el 27,enero 2016 - 09: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? |
| |
| |
| | | |
|
| | |
| |
| Publicado el 27,enero 2016 - 12:00 |
Hi Guenter,
i am using Internal Windows in combination with a Dynamic TabControl. Works quite well for me.
Cheers,
Sascha |
| |
| |
| | | |
|
| | |
| |
| Publicado el 27,enero 2016 - 12:45 |
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.
Thanks,
Ned! |
| |
| |
| | | |
|
| | |
| |
| Publicado el 27,enero 2016 - 14:08 |
Guenter
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. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 27,enero 2016 - 17:01 |
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 ay 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. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 27,enero 2016 - 17:29 |
Guenter
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. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 27,enero 2016 - 18: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. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 27,enero 2016 - 19:18 |
Quote
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! |
| |
| |
| | | |
|
| | |
| |
| Publicado el 27,enero 2016 - 19:48 |
Guenter
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. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 27,enero 2016 - 22:17 |
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! |
| |
| |
| | | |
|
| | |
| |
| Publicado el 28,enero 2016 - 03:48 |
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. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 28,enero 2016 - 23:43 |
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.
Regards,
Piet |
| |
| |
| | | |
|
| | |
| |
| Publicado el 29,enero 2016 - 05:51 |
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.
Cheers,
Sascha |
| |
| |
| | | |
|
| | |
| |
| Publicado el 29,enero 2016 - 06:29 |
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!
IW_Test02.7z |
| |
| |
| | | |
|
| | |
| |
| Publicado el 29,enero 2016 - 06:35 |
| 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. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 29,enero 2016 - 09:37 |
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.
Regards,
Piet |
| |
| |
| | | |
|
| | |
| |
| Publicado el 29,enero 2016 - 10:28 |
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 |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|