Stephen,

I tried to reply your e-mail but one of the IP (public) on the way is listed in the black-lists for SPAM.
Just to let you know that I'm finishing the adjustments in Leo regarding the millicolumns, which I want to publish later.

Stay tuned.

Is there going to be an option in preferences to use millicolumns or not?

I ask this mainly because Jack hasn't officially released the millicolumns version of A-Shell.

FYI, the latest millicolumn-enabled beta test version of A-Shell is 1139.3, available at http://www.microsabio.net/dist/51dev/temphold

As far as I know, it is compatible with existing programs (other than LEO) that don't know about millicolumns (although any further confirmation of that would be appreciated).

Unfortunately, the switch caused all kinds of conflicts in LEO which is Jorge is hard at work resolving. And there is also the potential problem that LEO might be used to generate millicolumn -enabled code that would then fail under earlier versions of A-Shell, so if it is going to support millicolumns, it would probably have to be an option. (Sorry Jorge).

It's available for update Leo "millicolumn" version.
My immediate concern was to teach Leo about millicolumns once there are a lot of calculations regarding to width controls of every kind, and parent coordinates, besides tons of variables needing conversion from b,1 to b,4 including many that were arguments in functions calling other functions, and so on
Once I was with my hands in the darkest parts of Leo code, I decided to free up the CTYPE2 argument of AUI controls that I was using for Leo internal control but, with the latest developments, this argument is starting to conflict with Leo.

So, now Leo work in millirows and millicolumns, but generate all the code in columns.
By now, this is safe because none of us will deliver in the next days (this week) programs to customers in millicolumns once they don't have compatible versions of A-Shell to run it.

The only caution needed now is to not place controls with right or left borders in "half-columns" which can produce code with the wrong width for those controls.

I'm still working in some details, like control the above case, but hopefully this update will allow us to move ahead in programming using the latest A-Shell version.

Not necessary to say that, please report any weird behavior, on my side, everyhting I could remember was tested, but there are always that case...

Here's a screen shot of a dialog in 5.1.1138.0



Here's a screen shot of the same dialog in 5.1.1139.3

Just now, coming here to say that Leo 3.0 is available, I'm seeing your last post Stephen.

I just didn't understand if this has to be with Leo or A-Shell; you notice the difference after generate in Leo, or is the same program running in different A-Shell version?

Leo 3.0 is now the only supported version and it's only compatible with A-Shell >1399 (millicolumns) version.
Anyway, the generated code is still fully converted to columns.

In the (new) Preferences - F2 panel, it's now possible to define Grid Width that should be set to 1000 in order to always adjust controls to absolute columns.
Also, all the other existing settings regarding columns, should be converted to millicolumns.

I probably shouldn't have posted that here. It was a reply to Jack's So, this is a problem w/ running the same program in different versions of A-Shell.

Jack,

I've downloaded the newest version 1139.7 from temphold, and downloaded the newest version of LEO and I'm still getting the pictured results from above. My dialogs are half as wide as they are with 1138.0

Here's the AUI call to create the dialog:

Jack, I tested this without MBST_CENTER and my dialog sizing is fine, so that's apparently the culprit.

Just so you know, I use MBST_CENTER for pretty much every dialog I create if it's not maximized to start with.

I believe this problem is fixed in 1140.1, which I just posted to the bin-win directory, along with the ashdevnotes in the 51dev directory. Incredibly, it had nothing to do with millicolumns, and was instead related to changes (also in 1139) to fix issues with dialog resizing.