I'm still working on the Form Editor.
The effort is divided into three parts.
Part 1 -Getting the design layout to display correctly.
As I stated previously, windows and dialogs are handled differently- fixed the code structure
I wasn't allowing for the various borders - fixed
I had not allowed for menus and statusbars.
Have added options for both in the form properties dialog
Currently working on drawing a dummy menu in the proper location at the proper time.
Todo - Do same for statusbar
Part 2 - make evertything appear in the proper location in the preview
Part 3 - make the generated code faithfully reproduce what the user has designed.
What has taken the most time has been figuring out and modifying the basic structure to accomodate the differences between windows and dialogs. After I got past that hurdle things have picked up speed quite a bit.
And since my mind wanders off on tangents I have figured out how I'm going to do something else.
I haven't implemented it yet but I've figured out an easy way to make a semi-demo that won't allow you to compile to an exe file but will allow you to look and play with all the IDE features. And since the code to compile is not present noone will be able to hack it to make it work. I'll address that after I get through with the form editor.
finished with part 1
about 25% of part 2 done
Part 2 is done.
Don't you just feel it in your water that this version is going to be the best ever,
thanks to the unstinting work of Larry? He's just not missing anything out - it's
obviously got more features now than anything we've ever had!
Keep up the good work, Larry,
Brian
Just discovered I've created a monster that is out of control.
If I had to do calculations only for a dialog it wouldn't be so bad because all the borders and stuff lie outside of the design area, as I discussed before.
And with a window they ultimately subtract from the design area.
And I was trying to make the design area look like the end result while it was being designed(caption, borders, menus, status bar) and was having to add/substract offsets for each.
Then I have to make adjustments to make the preview appear correctly.
Then I have to generate another set of adjustments to get the numbers right for the code generation.
If I could get part 3 done I would have such a conglomeration of code I wouldn't be able to maintain it six months from now.
Rethinking what I'm trying to accomplish I've come up with this.
When a user is laying out the controls on a form their primary concern is the appearence and alignment of all the controls within the client area of the form.
At that time having borders, captions, and menus is not really important; but status bars are.
By eliminating all except the status bars than the adjustments become very simple (gets rid of over 100 lines of code).
The preview is there to show the user what the end result will look like.
The values used to generate the preview will be almost identical to that used to generate the source code.
Sooo.....
I'm starting over at Part 1.
I think the end result will be a higher quality product that does what the user needs done.
Don't dialog units have something to do with screen resolution in some way?
Seem to remember Paul discussing this a while back...
Brian
you're correct. However, the CREATEDIALOG and CONTROL commands take care of those calculations for us.
That's why we can enter control parameters in pixels relative to the upper left corner of the client area of a window/dialog
Most of the problems I've encountered are due to the approach I took in the design of the form editor.
I basically took what the current dialog editor does and adapted it to handle windows + menus + statusbars +toolwindows.
Had I started from scratch I think I would have taken a different path(which I'm doing now).
Already finished with the new Part 1 and Part 2.
Part 3 is done - that was fast with the new scheme.
One last little bit to do - to make the eventual form size show during design