Oftentimes, when I use the window formatter, the actual run-time result does not match what I thought I had originally set. This causes me to spend a lot of time with trial/error, and ultimately write some code to line the problem controls up using PROP:Pixels.
I would be interested in hearing if anyone has a technique for getting things lined up without these kinds of issues.
The problem (the way I think I understand it) stems from the window formatter being able to move things at the pixel level, but there isn’t an exact DLU number to accommodate that coordinate. So when you save the window structure, it has to convert the actual coordinates to DLU as best as as it can.
It would be neat if somehow we could extract, at the pixel level, an array of coordinates while using the Window formatter, so it could be applied at run-time to fix things up with a class.
Simplest, would just be a PIXELS attribute on the window.
That might help for some stuff, but even having the DLU number doesn’t mean it won’t be xx pixels off from where you thought you positioned it visually. You can’t get the level of granularity that will allow you to make a perfect window, then save/open it and have it look the same as it did when you saved it.
An example of what I’m talking about: Try selecting a control and moving it to the left several times (with the left arrow key). Sometimes it will increment the X pos, sometimes it won’t. It seems like that’s because the window formatter seems to think in pixels, and that’s a lot more specific than DLUs can handle, so you lose some precision.
Not saying I liked C6 better, but at least, in C6, the window formatter was pretty dang WYSIWYG, and that seems pretty important.
Don’t get me wrong, Jeff, as someone that grinds on good window layout and flow I’ve hated the current designer for this very same reason.
The IDE was originally chosen to host Clarion# and the framing in the IDE that wraps around the AppGen is all dotNet which, as I understand it, based on pixels not DLU’s that Clarion uses. The designers were originally designed for dotNet.
I’m certain you, like myself and a lot of others, have noticed the “disconnects” between the AppGen and the surrounding IDE. Unless things have changed the AppGen is Win32 floating within the dotNet IDE. Things like not being able to use CtrlS within the AppGen to save it even though the IDE menus have CtrlS indicated as a shortcut for Save. That’s just one example that makes me want to scream but that would just hurt my throat and frighten anyone nearby!
There are parts of the IDE that lost functionality since C7 - I would never disagree about that.
I find putting a bunch controls in a GROUP the best way to move them without any “jitter” of individual controls. I typically do that in the Window… Editor. I find it easy to find the first control and insert a GROUP above it AT() that controls X,Y -2, then an END after the last.
E.g. if I want to move ALL the controls … the only way I know is a Group. Just add after the WINDOW a GROUP, AT(0,0),USE(?GAll) then an extra END last.
I usually move the Group by changing the X,Y numbers in the Properties, but I think drag works also. I often have to change the Group X,Y in the Window… Editor so it does Not move the child controls, mainly if my Group X,Y was not tight enough.
