Parent MDI Form last tab

[itg-assistant]

Alex Prinias asked 2016-09-09 14:19:23 UTC

Hi guys!

Trying to make some decisions and I would like your enlightenment on the following:

In an MDI Form configuration, is there the possibility to have access to the last tab, the one with the pictures of all the other "real" MDI Children Forms?
In particular,
a. can we hide it with a Visible property?
b. can we access the individual form pictures and allow/disallow their drawing or draw what we like instead of the default?

A more general question: if we forget this last tab, what is the real difference between a MDI Parent form with tabs and a simple TabControl? i.e., what can we do in an MDI form which cannot be done with a TabControl?

Best

[itg-assistant]

Frank (ITG) answered 2016-09-09 15:01:57 UTC

Hi Alex,

the preview page can be hidden but the property is not exposed yet (logged WJ-7580 for that enhancement).

The form pictures are actually no real pictures but a disable and scaled cloned dom (due to technical reasons).

You could build an alternative MDI system where forms can become children of other controls, including a tab page, etc.

Hope that helps.

Best regards
Frank

[itg-assistant]

Alex Prinias answered 2016-09-09 15:41:17 UTC

Thanks Frank.

The form pictures are actually no real pictures but a disable and scaled cloned dom (due to technical reasons).

cloned dom? This means that if I have very complex/heavily populated with controls forms, these are duplicated to create these "pictures"? What is the effect of this on rendering performance? Now, I'm worried! :)

Best,
Alex

[itg-assistant]

Luca answered 2016-09-09 15:57:20 UTC

Cloning the dom is very fast, almost instantaneous, since the nodes are already created with their attributes and styles. The rendering process is when the widget library creates or updates the dom elements by translating the widget properties to the equivalent dom representation: class name, attributes, and inline styles. That is heavy because the browser processes the changes as they are applied (if you set the width of a dom element 100 times the browser will updated everything affected 100 times) and then renders the page in frames.

Wisej (thanks to qooxdoo that implemented a fast dom technique early on) caches all changes to the widgets and "flushes" them at once. So if you change the size of a widget 100 times in a response cycle, it gets applied to the actual dom only once.

VWG used a completely different approach, they didn't have a widget library and created HTML on the client by transforming an enormously complex XSLT document to HTML and then replace the nodes. That is why it was common with VWG to lose the focus if the code changed any visual attribute of a text box, for example, because the client destroyed and recreated the element every time. The result of that technique was that the initial creation was faster than Wisej, but the maintainability/flexibility of the template, handling of the page, and subsequent updates turned into a nightmare.

Ciao,

Luca

[itg-assistant]

Frank (ITG) answered 2016-09-09 22:53:32 UTC

Hi Alex,

WJ-7580 has just been added to the latest build (1.2.58)

Best regards
Frank