Diese Seite mit anderen teilen ...

Informationen zum Thema:
WinDev Forum
Beiträge im Thema:
Erster Beitrag:
vor 1 Jahr, 10 Monaten
Letzter Beitrag:
vor 1 Jahr, 10 Monaten
Beteiligte Autoren:
DerekT, Victoria Caballero, Steven Sitas, GuenterP, Fabrice Harari

[WD20] MDI window issues

Startbeitrag von Victoria Caballero am 28.08.2016 12:59

Hi everyone,
I have an issue with MDI main window and I hope someone can help me :-).

I am working on a new project in WD 20. Have started this project like 6 months ago... So in the beggining of the project I asked my customer which kind on menu wanted. They told me they just wanted to be able to open one procedure at the time so not MDI menu was requerid. So we created a main window with a simple menu on the left side using buttons for each option of the menu, this is how it looks:

So now my customer has changed his mind and wants to be able to open several windows at the same time for example open Clients window and then open Applicants window and later settings window for example always leaving the other already open.

So in order to do that need to convert the app in an MDI project. This means I need a Main parent window and the rest of rhe windows has to be converted into MDI Child windows.
So I have created a new parent window to redesign the main menu and I have tried to use a toolbar, a ribbon menu and some free buttons placed on the left but when testing the window none of them work...
Like this: http://screencast.com/t/5OMwaAwSk

The only thing working are the options placed in the main menu on top of the window. So if I click in any of the buttons in the toolbar, or ribbon menu or free buttons none of them work, they do not do anything. So my question is.. is that even possible? am I doing something wrong?

Working with another development tools creating a MDI app means the main window can only have a bar menu and nothing can be placed on the background of that window.... so maybe the same is applied in WD but the window editor allows me to add a ribbon, a toolbar and some free button in the body of the window but I cannot use them... why?

Any comment or advice will be appreciated.



Hi Victoria

First, I have o disagree with you :-)

When you are saying:

>>So now my customer has changed his mind and wants to be able to open several windows at the same time for example open Clients window and then open Applicants window and later settings window for example always leaving the other already open.

>>So in order to do that need to convert the app in an MDI project. This means I need a Main parent window and the rest of rhe windows has to be converted into MDI Child windows.

I COMPLETELY disagree...

You can do that by replacing your OPEN by OPENCHILD (not MDI, regular windows), and manage or not the position of the child windows (either blocked inside the mother or free) by code...
That's what I'm doing in WXEDM...

You can also do that with INTERNAL windows (by example in dynamics tabs).
That's what Steven is doing in alpha360.

The advantage of NOT using MDI is that you don't have to deal with all the problems coming with an obsolete technology even abandoned by M$ in their developments (even though THEY developed it)...

As for what is possible or not in MDI:
I know for a fact that a ribbon and other toolbars are NOT standard in MDI, but that you -COULD- manage them, mostly by using api calls to modify MDI area and so on... However, it always has been a pain in the ass to do so, as MDI does NOT want you to do it.
As for why you can add these features in a windev MDI window, I'm GUESSING that it's because PCSoft has abandoned that technology, like everybody else, and just kept the option for compatibility. This means that all the NEW TOOLS, like the ribbon, do not have code dealing with the MDI case.

So you can still do PURE MDI (if I remember correctly, Guenter is still working that way without problems), but I doubt anything more modern will work properly with it.

Best regards

von Fabrice Harari - am 28.08.2016 14:08
Hi Fabrice, this one may become a bit longer, excuse me if I just have to stop somewhere in the middle ..

1 - a "Ribbon" control is nothing else than a bunch of buttons with popup menues. So, it should work properly on MDI parents and as well on MDI child windows. However, I avoid to add any menues on MDI cild windows. One can do it, but after some time and several hundred windows you can't see through the mess you you've made.

2 - MDI. Real MDI had to be abandoned because of the rules delivered together with MDI. Yes, the usual use case (a maximized parent with a dozen MDI windows floating around in the free space of the parent's belly) isn't anymore modern, it's a pain in the ... One of the bad rules is: if you maximize one child, all of the other childs will be maximized. Unbearable. Don't use MDI in this way!

3 - I'm using MDI in a very different way! All of the child windows are maximized when opened and each one fully fills the space of the parent window. For users, there's no way make the child window smaller than the parent's frame, it stays maximized. If one changes the size of the parent, the child window will change in size too and will always fill the parent's frame. The MDI child windows open on top of each other, when using a "normal" menue control one could have a list of the opened windows. I avoid that in order to force users to work down their windows from top. There's a second reason for not using a simple menue control - it carries those three buttons (minimze, maximize ..). So, I'm using either a ribbon or popup menues. In effect, I have a kind of home-brewn "internal windows" since version 9. Still working together with my (a bit modified) RAD 11.

Looks like that:
[attachment 2139 Ashampoo_Snap_2016.08.28_17h29m55s_001_HauptmenvonBckereiPlus-2-0--TabellenLS-Kpfe-LS-Zeilen-.png]

Note: the "menue" on the upper border of the parent is a bunch of buttons - each one opens another popup menue.

4 - Having several child windows open at the same time gives you another problem to solve. Changing / adding anything on the topmost window will have to be reflected on the other windows. So, there are some procedures to program to update those windows when they gain focus.

von GuenterP - am 28.08.2016 15:34
Hi Victoria,
as Fabrice said, stay away from PURE MDI - this is obsolete technology.

Older Clarion developers remember the various problems it caused in Clarion 5/6 - it was a nightmare and SoftVelocity had to do zillions of workarounds to make things work.

If you are talking about MDI in a CONCEPTUAL way, you can use openchild etc.

Now, if you allow me some comments on your screens:

1. The first one looks clear and easy for a user to understand. I like this one ...

2. The second one - at least for me - is confusing and the "problem" is your use of the Ribbon menu. MS pioneered the Ribbon in MS Word/Excel to give a user access to hundreds of actions, "IN" a document. What you are trying to do is use it as a kind of Toolbar/Menu. This is overkill use of the ribbon, I think ...

You could use a ribbon, say, when you are "IN" an Invoice document - if you had many many actions - but not as a menu.

Of course UI is something very personal ...

You can see our main idea of a UI - www.alpha360.biz
There is NO copyright on the UI and you can freely copy or change it to suit your needs.

In 2 weeks we are going to post a more complete version of the apha360 erp project and there you will see many interfaces an end user can choose from dynamically ...

Steven Sitas

von Steven Sitas - am 28.08.2016 15:45

This is correct but you can reduce the size of the MDI working area (where child windows display) by dragging this region of the MDI Main from either the left of top to expose areas where any control can be placed.

I do however have to agree with Fabrice and say that this is not the ideal solution.
Dynamic tabs + internal windows are probably the best option moving forward but may require a lot of work for you as you are converting an existing app.
Depends how many windows you have at present - there is no option to convert a 'free' window into an 'internal' type and overall the handling of internal windows is different.
You would end up with a good looking and flexible interface though.

von DerekT - am 28.08.2016 15:47
Hi Derek,
>> there is no option to convert a 'free' window into an 'internal' type

I do it all the time in the IDE.
Open the Window in the IDE -> Save as Internal Windows
It has been there since v20 and maybe earlier ...

If you mean in runtime - you are right, you cannot do it.

Steven Sitas

von Steven Sitas - am 28.08.2016 16:24

Thanks for the info - I had never noticed that option.

That being the case I would definitely consider the dynamic tabs + internal windows as your solution.

von DerekT - am 28.08.2016 17:21
Thank you very much to everybody to answer so fast since I posted the message today and during the weekend :-). I really appreciate all of your answers guys.

Fabrice... you are actually right about replacing OPEN for OPENCHILD, I think that will work in my case... probably just need to change my code. Thanks.
I also like your suggestion about using Tabs, I would like to implement this but I think I will need to change my windows and convert them into Internal windows right? As Steven said in his message below it is just a matter of "Save as an internal window..." internal window right? Would that be enough then?
I also agree with you that MDI model it is an obsolete technology and I am happy to see now that I have some other options to that and still be possible to build a nice and functional interface for my customer.

Guenter... I also like your implementation with the list on top showing the windows already opened. I just wonder how difficult could be for me to implement it in my project.

Steven... I am a Clarion programmer too :-). In Clarion you can still implement this old MDI technology fairly easy but I also agree this is an old obsolete technology.
Thanks for the link to alpa360. I really like your L&F, it is clean, flat and modern. But my customer loves MS Outlook style and he wants me to achieve this style for his application, therefore I am trying to do that some how.
I would like to still have the bar menu on the left side of the window (the one I have in my first screenshot) like you Steven have in alpha360 tool. Also the Tabs it is a nice implementation.
The second screenshot it is just a test window... I was trying to figure out the possibilities of implementation in a Parent MDI window... but I think I will drop this idea.

DerekT, I also like your sugestion about using Interrnal windows and Tabs. That might be the way to go I think :-)

So all of your comments has given my a lot to think about and that is a good thing :-).
I just have some further questions regarding your comments....
Is there a limit in the number of Tabs that I might have open in the main window?

My customer loves ribbon menus so he wants me to use it on every window we have... he wants me to replace all the buttons I have in the windows now (new, edit, delete, cancel, save, etc) and place them on a ribbon on top of each window. I am not sure if this could bring some troubles in the future since I have not used ribbon on my projects so far. I also like them visually but I will appreciate any comments or sugestion about drawbacks that might happen by using them.

I cannot find any example of Dynamic tabs in WD 20 however I have an example in LST 101 so I will take a look to it to explore the available options.

So again thanks to all of your answers guys. I appreciate them.



von Victoria Caballero - am 28.08.2016 18:45
I have an app I am currently working on that uses Dynamic Tabs with Internal windows.
Each internal window has a ribbon which I use as a menu - each ribbon grouping (tab) has its own set of buttons.
These in turn call their own internal window.
To control this each ribbon grouping (tab) uses its own plane.
Initially I had a single internal window control but a bit of testing indicated that having an individual IWC on each plane represented little or no overhead either in operation or size of the compiled exe so I now use this option.

I will do a few screenshots tomorrow with a bit more explanation.

And to answer you question:- there is no advised limit as to the number of dynamic tabs that can be opened although memory and overall usability may be an issue.

von DerekT - am 28.08.2016 19:56
Hi DerekT,
thanks for your last answer, it really help me your comments and explanations.
Appreciate the screenshots if possible.


von Victoria Caballero - am 29.08.2016 07:02
Hi Victoria,
we just did a new YouTube video, showing our FULL UI implementation.
It is on our website www.alpha360.biz

Here is what it does ------------------

A user can select, dynamically, between the following UIs:
- Simple
Open one form at a time, outside the dynamic tab
- Multi-Windows
Open many forms, outside the dynamic tab and switch between them
- Flat
Open many forms inside the dynamic tab and switch between them
All of the UIs automatically notify the appropriate windows so they can refresh themselves.

Steven Sitas

von Steven Sitas - am 29.08.2016 12:11
Hi Steven,
thanks for the info.
Sounds interesting all the UI features you describe. I will take a look now.


von Victoria Caballero - am 29.08.2016 12:33
The app uses a standard main menu on the main window however this can of course be placed at the side by using a Sidebar or a series of buttons.
The only consequence of this would be a reduction in the available display area (width) of the Dynamic Tab control and therefore a constraint on the amount of data that can be displayed on each tab.
This in itself is not necessarily an issue as, dependent of your setup, you can enable the ability for each tab to be dragged to another area of your display or indeed another monitor.

Code needs to be written to control and record the opening and closing of the individual tabs either as a set of global procedures or, as in my case, class methods.
This basically just adds/removes rows from an array subject to any overriding logic defined which in my case includes the setting of the tab captions, control of duplicate windows being displayed and the total number of active tabs opened.
In addition I, conditionally, populate a second array which is used populate a dropdown accessed from the Navigation menu option to allow users quick access to previously opened windows – my limit is 25 based on the FIFO principle.

Selection of any menu option will open a new tab (or re-display, see above).
Note that each tab is in fact an internal window control therefore any window called in the ‘open’ code must be of the internal type.
Typically for me this will display a list or static information and therefore is displayed as is without the need for planes.
I use a ribbon control as my menu – generally only a single grouping (tab) is required.

Clicking on a menu button e.g.Detail will open another tab.

Again the ribbon is used as a menu but generally multiple groupings (tabs) are required.
Initially I had a single ‘internal window control’ where each button in displayed on the tabs simply changed internal window to be displayed.
Have to say that this did not work well as the delay was very noticeable waiting for the closing processes of the current IW and initialization processes of the called IW to complete.
Following testing I found that the overhead of having a dedicated ‘internal window control’ for each grouping (tab) was negligible both in the size of the window and the generated exe.
I have now implemented an IWC per Tab policy with each IWC sitting on its own window plane.
The offers two distinct advantages……
1. The display of the called IW (Plane change) can be delayed until the aforementioned closing/initialization code of the windows has been run.
2. I can determine, in code, whether the window called has already been opened and decide whether to refresh the display or display as is.

A ribbon can contain any number of buttons and or edit controls subject to your needs.

A final decision is on how to implement the adding/editing of the displayed records.
I note that Steven in his Alpha360Biz has opted for the traditional ‘modal’ popup and indeed I initially did the same.
On reflection however I concluded that this somewhat defeated the object of having multiple dynamic tabs as it defeated the option of being able to access/review any of the information available especially if dragging/multiple monitors were employed.
As a result I now display a dynamic tab for these operations.

To avoid chaos however this does need to be managed which I do by….
1. Only allowing one such widow per type (Landlord, TenApp etc.) to be open/active.
2. Setting a timer (currently 6 mins) to automatically close the window – user is notified after 3mins - if the operation is not concluded.
3. Automatically close the window if the calling window is closed or its content changed.

As only two outcomes can achieved, Save or Cancel, no ribbon is used.

So there you have it, my take on Dynamic Tabs.
I should clarify all this by explaining that this project is in fact a re-write of one of my older applications – you guessed it written as MDI – and initially started as a proof of concept for the use of the MVP Rad released in v20.
As such it is a bit scrappy in places but I do quite like both Dynamic Tabs and MVP so guess I will tidy it all up and complete the task at hand.

If any of this rambling is not clear please ask – I will answer if I can.

von DerekT - am 29.08.2016 13:49
Hi Derek,

nice work !!!
As you say the main problem is how to "avoid chaos".
You probably saw the first video - where we showed the traditional "modal" popup interface.
We posted a new video, an hour ago, showing our FULL interface. A user can dynamically select his interface (Simple, MultiWindows, Flat).

To be honest, I do prefer the traditional "modal" popup.
You said something about DELAYS when closing processes of the current IW.
We had these in WD20, but we haven't seen them in v21.

Steven Sitas

von Steven Sitas - am 29.08.2016 14:16
Just watched the vid, good effort.
Interesting approach to have this user selectable - had never occurred to me but I can see some advantages especially if this was tied in with user roles.

Must admit I have not revisited the shared IWC delay issue since I adopted my plan B.
Guess that maybe PCS have done some optimization in this area.
Doubt I will change now but of course I will still get the benefit when opening and closing tabs.

von DerekT - am 29.08.2016 15:52
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.