z/tab order problem? just me, or bug

Started by Slavko Ivanovic, April 06, 2009, 12:23:41 AM

Previous topic - Next topic

Slavko Ivanovic

I'm experiencing problem with ODCL studio 5.1.0.2.

In studio z/tab order is reversed.
If control is on top, studio displays it below.
If I send control to BACK, its definitely on top.

Completely reversed.

I'm running winxp sp3 32bit, and its the same on both, my desktop or notebook.

I have downloaded -April 6, 2009 alplha-  ver. but its the same.
Am I alone with this, if not wtf?

note: in runtime (ACAD) everything is ok,
but its very annoying cause in studio i cannot see the real preview,
and of course i must select control from properties palette, cause i don't see
controls exam. if i have tab control. It shows on top everything. 

But ver. 5xxx is beautiful in any case.
***  siCAD Solutions for AutoCAD  ***
ArchiTools l ToolsPlus l LandTools l LBE

Slavko Ivanovic

***  siCAD Solutions for AutoCAD  ***
ArchiTools l ToolsPlus l LandTools l LBE

Fred Tomke

Hello,

did you try displaying the form in AutoCAD? Then the order of controls will be displayed correctly. If I understood Owen right, there are some limitations showing the correct order in OpenDCL Studio. But in AutoCAD it will be display correct.

Fred
Fred Tomke
Dipl.-Ing. (FH) Landespflege

[ landscaper - landscape developer - digital landscape and urban design]

Slavko Ivanovic


Hi Fred. Thanks for reply.

I already said in my first post that in run time AutoCAD my forms
are OK - respect settings from z/tab order palette in studio.

In ODCL Studio 4.1.2.2 i was made 35 completed projects, and i never experienced
z/tab order display problem. Always the same look in studio & runtime.
Anyway I was waiting 5*** version to go stable, i now I started migration of old and
developing a new projects.

The thing is:
If ODCL Studio has some kind of Windows limitations that cause  Z order confusion,
why Studio displays Z relations perfectly correct but when U reverse wanted order??

In other words in Studio everything is just fine, if I reverse order.

PS. I improvise like this - First i manage every positions reversed to be able to see
correctly in studio, then before testing, i reverse every control to wanted order.
I don't see any other way.
That's why I post all this.

Can this be fixed, if it's not problem only on my PC's.




***  siCAD Solutions for AutoCAD  ***
ArchiTools l ToolsPlus l LandTools l LBE

Fred Tomke

Quote from: Slavko.Ivanovic on April 06, 2009, 04:57:15 AM
I already said in my first post that in run time AutoCAD my forms
are OK - respect settings from z/tab order palette in studio.

Sorry, I have missed it. I'm not sure if this could be fixed. I don't know exactly, but it could be introduced when transparent controls and VisualStyles were introduced in OpenDCL, but I may be wrong and I don't want to spread rumors. Owen could say more about this. As far as I know he has already tried various things to solve this.

I must say that most of my controls do not overlap each other: frame is shown transparently anyway and in all the other cases (rectangle or picturebox in the background) I ignore the wrong order in Studio.

We would be glad about any further suggestions about that.

Fred
Fred Tomke
Dipl.-Ing. (FH) Landespflege

[ landscaper - landscape developer - digital landscape and urban design]

owenwengerd

Fred is correct. The problem is that Windows optimizes the painting of controls in such a way that it is impossible to control painting order of child controls on a dialog. Microsoft even says that Windows does not support the overlapping of controls.

Various things can affect the painting order, including Windows version, display driver, visual styles, etc. The problem is exacerbated in Studio because the actual controls are contained inside a host window.  Not only are they overlapping, they are not even siblings on the dialog. At least at runtime the controls are all siblings with a common parent, so there is some opportunity to manually repaint them in the correct order (at the expense of performance).

I have tried various things to make the problem less noticeable, and those who remember some of the early alpha builds will realize that the situation has improved somewhat -- but to date I haven't found any solution that works in all cases.

Slavko Ivanovic


OK. I get it.
Thanks Owen for your time.
I appreciate it.

After all it's a such a microscopic issue, in a fantastic
functionality of this project, that gives AutoLISP interface power,
that he deserves.

Excellent job.
***  siCAD Solutions for AutoCAD  ***
ArchiTools l ToolsPlus l LandTools l LBE