I think I’ve located two bugs for Cartwall. I have 3.1.1, build 789 (latest snapshot)
Under configurations, I have cartwall enabled. Once I open Layout Manager, I receive an ‘Access Violation’ error. I can click the dialog box and move past it to the layout program.
Cartwall is opened from the toolbar on the playout and is maximized. If an empty cart is clicked on, the Cartwall screen can no longer be closed or minimized.
EDIT: Additional, both these problems occur when ‘Open in Separate Window’ is checked in Config Utility. I believe that the problem does NOT occur when the option ‘Embed in Main Window’ is chosen.
I’m traveling and don’t have the machine in front of me, but if you need additional info, please ask.
I will, although I’m away from the machine for a least several days. I’m currently traveling, so I may not be able to send them until Monday or even Tuesday. Hopefully, that is not to late.
(FYI: the details dialog button is displayed on only the first issue, not the second.)
Regarding issue 2, it occurred everytime that I tested before I sent a bug report. Could it be that I have a conflict configured in Config Utility? Also, perhaps it’s related to some earlier modifications: I made a post regarding the Cartwall failing to keep its position over the browser. One of the suggestions was to eliminate the cartwall entry in one of the config. files (don’t remember which one). At that time, the browser was the dominant object, and thus the Cartwall couldn’t be moved or placed over the browser.
Perhaps you can just sent me all of your config files (without the passwords, of course), and I will try to reproduce it with your config.
Regarding the cartwall vs. browser question, it’s basically the creation order that determines the “vertical” position (Z order) of all GUI elements. The cartwall is created before the browser, so it’s below the browser.
Delphi does provide a way to change the Z order, but only through a method named “BringToFront” which can be called for a particular GUI element which will then be on top of any other element. It’s not so easy to offer a Z order option in layout.ini and translate it to the correct BringToFront calls, I guess. But I can try.
Oh, and when the cartwall is in a separate window, things are different. The cartwall window is in “stay on top” mode, so it should always be above the browser. It’s position is determined by (a) the layout.ini and (b) the position.ini file. In the latest versions, layout.ini should always have higher priority.
cough< That’s pretty easy, actually. And while we’re at it, I would call it the ‘depth’ position rather than the ‘vertical’ position.
So … in each layout.ini section, you have a setting called ZOrder (may as well be literal about it!), where a value of 0 (or 1, if you prefer) is the ‘topmost’ or ‘on top’ value, with other sections’ ZOrder being increasing integers (1, 2, 3, …).
At initialisation time, you just draw all the objects, then call BringToFront in descending ZOrder order (say, 3 first, then 2, 1, and finally 0). Job done. 8) Any object which does NOT have a ZOrder value can either be treated as a 0 (on top) or ignored (equivalent of ‘leave at back’): your choice. Objects with the same Z-order value should be ‘BroughtToFront’ in the order they appear in the layout.ini file. That makes it consistent with properties in skin.ini (in the sense that ‘the last matching entry “wins”’) AND makes it easy for the user to have total control over this.
So, in this way, the user can simply and optionally design their own Z-order for their layout, with relatively little programming effort required by the good Herr Doktor. ;D
Er … as I have only a single monitor on what Torben refers to as my ‘antique’ PC for mAirList testing, I’ve had the Cartwall in a separate window since the start. And when mAirList starts, the Cartwall window is always ‘under’ the main mAirList window. Perhaps there’s a setting being saved in a .ini file that I haven’t noticed?!! :-\
