Index
> IDE Development > Fresh controls design time information specification. |
| Author |
|
|
JohnFound 20 Sep 2003, 15:44
This too unreadable on my display, so here are actual files:
[EDIT] Removed attachement. See below in the thread for recent version. [EDIT] Last edited by JohnFound on 20 Sep 2003, 19:10; edited 1 time in total |
|||
20 Sep 2003, 15:44 |
|
|
scientica 20 Sep 2003, 16:03
Looks nice at first look, this is what is needed, a clear structure. I'll look more into it, I've gotten a wild idea on how to make the styleeditor better - but I think I'll have to complete the current type before trying out my ide (it would probably require some owner drawing/custom controll coding).
_________________ ... a professor saying: "use this proprietary software to learn computer science" is the same as English professor handing you a copy of Shakespeare and saying: "use this book to learn Shakespeare without opening the book itself. - Bradley Kuhn |
|||
|
20 Sep 2003, 16:03 |
|
|
JohnFound 20 Sep 2003, 16:28
scientica wrote: Looks nice at first look, this is what is needed, a clear structure. I'll look more into it, I've gotten a wild idea on how to make the styleeditor better - but I think I'll have to complete the current type before trying out my ide (it would probably require some owner drawing/custom controll coding). If your idea is good, I vote for it.  If you want we can discuss it first.
BTW: Another work I make these days (but it is in very early stage, so I will post it later) is special grid that will handle the properties of the components more in common way, than now. It will look similar to Delphi property editor - grid with two columns - left for property name and right with editor for this type of property. For example, the button in "Style" row will call your style editor. Description for every property will be in the above design-time info structure too. regards. |
|||
|
20 Sep 2003, 16:28 |
|
|
scientica 20 Sep 2003, 18:07
[edit]Yor delphi like grid, sounds great (I look forwar to see it), it would possible remove the subtype from the style editor and put it in the grid.
(Got thrown offline "a few" minutes, so the conent is a bit old - haven't had time to check the board for new posts) [/edit] Code: ;I've decide to begin work on the java doc when this is discussed - so that I ;avoid coding things that will become obsolete. One of the biggest issues for ;me has been where to look for the information, function, definitions, etc. ;What about adding a function GetSelectedControllDTI (DTI=Design Time Info), ;which return the pointer to the DTI struct for the currently selected controll? ;This would make it easier to get the info, now it feels a bit like there is some ;over-head sending the pointer to the TBaseWin a cross the sources, it would IMO ;be easier with funcitons like GetSelectedControllDTI and preferably a funciton ;named GetSelectedControllTBW (TBW=TBaseWin). There could alternativley (or ;inclusive) be a global variable that hold this info. ; ;I've made some more thinking, and maybe there is no need for custom controlls, ;The "dialog" below is how the style editor could look like, the problem would be ;if there would be two or more subtype fields, then the subtype would need to be ;re-written. ;The idea is to have the subtypes a drop down box, that way only one subtype can ;be selected. ; ;The flags, the default style is a very good thing, since it enables the ;introduciton of the "Restore to default" button, which restores the controlls ;default style. ; ;As you can see the style editor is three divisions, the caption (which is a part ;of the window/dialog) is always present. The subtype division is only present if ;there are any subtypes defined. The flags are also only present if the controll ;uses it. ; ;It's just thinking, and needs some discussing. ; ;Maybe the TDesignInfo should contain this as well, IMO the controlls should at ;least have a propper name as tooltip on the button/image the user Clicks when ;(s)he's is about to add it to the form. ; .ToolTip dd ? ; pointer to tooltip text, eg "Group box", "Button" ;+-------------------------------------+ + ;| Style Editor [X] | |- Always present ;+-------------------------------------+ + ;| Subtype Name: [sybtype [v] | /- Present if SubtypeName != 0 {.SubtypeName + ":"} ;| Flags: [Restore to default] | + ;| +---------------------------------+ | : ;| |Flag | Value | Description | | : ;| +-------+--------+----------------+ | : ;| |_______|________|_______________^| | :- Present if Style(Ex)Names != 0 ;| |_______|________|_______________#| | : ;| |_______|________|_______________#| | : ;| |_______|________|_______________#| | : ;| |_______|________|_______________v| | : ;|_____________________________________| + ; ; ;This would require the introduction of .SubtypeName dd ? ; pointer to subtype name ; ;and the .SubtypeRange would need to be re-written to something like this: .SubtypeRane dd ? ; pointer to subtype range struct ;Here is how the struct could look like: struct SubtypeRange [_value, _nme]{ common index=0 forward index=index+1 common dd index ; number of subtypes reverse local n0l, n0 dd _value ; value dd l0n ; precomputed length n0 db _nme,0 ; name ln = $-n0l } ;----------------------------------------------------------------------- BUTTON.asm: ... DesignTimeInfo \ \ ; 1. BUTTON CONTROL 'BUTTON', \ $54010F00, \ ; default style $0, \ ; default ex style 64, 25, \ < \ ; style names 'BS_LEFTTEXT' , 0020h, "", \ 'BS_ICON' , 0040h, "", \ 'BS_BITMAP' , 0080h, "", \ 'BS_LEFT' , 0100h, "", \ 'BS_RIGHT' , 0200h, "", \ 'BS_CENTER' , 0300h, "", \ 'BS_TOP' , 0400h, "", \ 'BS_BOTTOM' , 0800h, "", \ 'BS_VCENTER' , 0C00h, "", \ 'BS_PUSHLIKE' , 1000h, "", \ 'BS_MULTILINE' , 2000h, "", \ 'BS_NOTIFY' , 4000h, "", \ 'BS_FLAT' , 8000h, "" \ >, \ NONE, \ ; style Ex names \ $5E00FFF1, \ ; This is StyleMaskAnd $40000000, \ ; This is StyleMaskOr $FFFABB3F, \ ; This is StyleExMaskAnd $00000000, \ ; This is StyleExMaskOr 'Button type' \ ; This is SubtypeName $00000001, \ ; This is SubtypeMask < \ ; This is SubtypeRange 0, 'BS_PUSHBUTTON', \ 1, 'BS_DEFPUSHBUTTON', \ 2, 'BS_CHECKBOX', \ 3, 'BS_AUTOCHECKBOX', \ 4, 'BS_RADIOBUTTON', \ 5, 'BS_3STATE', \ 6, 'BS_AUTO3STATE', \ 7, 'BS_GROUPBOX', \ 8, 'BS_USERBUTTON', \ 9, 'BS_AUTORADIOBUTTON' \ > \ NONE, \ ; Library file NULL, because it's standard component. 'imgButton.bmp' _________________ ... a professor saying: "use this proprietary software to learn computer science" is the same as English professor handing you a copy of Shakespeare and saying: "use this book to learn Shakespeare without opening the book itself. - Bradley Kuhn |
|||
|
20 Sep 2003, 18:07 |
|
|
JohnFound 20 Sep 2003, 18:42
Hi, scientica.
Thanks for the additions. I am agree with almost all, with one small note: I think that "Button" control must support only those Subtypes, that are really buttons. For example, BS_GROUPBOX defines group box, not button, so this subtype will be descrybed as different control - "Groupbox" with classname "BUTTON" and only one subtype: BS_GROUPBOX. The same for checkbox, radiobutton etc. I don't know why MS made all this different controls in one windows class and actually I don't care, you know that in Fresh controls palette these controls are diferent. IMHO, it's not good idea to allow converting from button to groupbox via property editor. scientica wrote:
So, the Button definition IMHO must looks like this: Code:
.........
'Button control' \ ; This is tooltip
$00000001, \ ; This is SubtypeMask
< \ ; This is SubtypeRange
0, 'BS_PUSHBUTTON', \
1, 'BS_DEFPUSHBUTTON', \
> \
NONE, \ ; Library file NULL, because it's standard component.
'imgButton.bmp'
Now I will convert the files acording your ideas and will attach them with my first draft about design-time executable code. Regards. |
|||
|
20 Sep 2003, 18:42 |
|
|
JohnFound 20 Sep 2003, 19:08
The last versions of specification with Scientica's ideas:
Only instead of new struct for Subtype data I am using the same structure as for styles information. I will not post whole specification here, because the files are too long. So download and read it. Here is first draft of design-time executable code handling - there are some problems without solution for now. 
[edit]Outdated attachment removed[/edit] Last edited by JohnFound on 12 Oct 2003, 15:13; edited 1 time in total |
|||
|
20 Sep 2003, 19:08 |
|
|
scientica 20 Sep 2003, 20:16
Great
I agree with your comment on the sub types, I didn't think of it. (and would probably not have thougt of it for long time). You could possible import those nasty (   ) globals from fresh.exe. Giving fresh.exe an export table -- you can export any label - even variables. (I've used this export table technique for debugging in the past, (in projects dead since long time ago - don't know if I have the source left)
Or. You could make it "easy", putting the globals in globals.inc, writing a function in fresh that works like this (see GetVairable). (import GetVairable in the dlls from fresh, and export GetVairable from fresh). <side note: "GV_" as in "Global Value"> Code: ; in globals.inc macro Global [var_name, NeedName]{ common varID = 0 forward GV_#var_name equ varID if defined isFresh var_name NeedName end if varID = varID+1 common if defined isFresh ; display number of globals - NB, one based number! DispHex "Number of global varaibles: ", varID end if } Global hInstance, <dd ?> Global hMainWin, <dd ?> Global .... ; in fresh: isFresh = 1 ; don't jsut define them, make them include 'globals.inc' ;... proc GetVairable, VariableID enter mov eax, hInstance ; or first global variable mov ecx, [VariableID] mov eax, [eax+ecx*4] return ;... ; in dll: include 'globals.inc' ; just genereate the GV_ for since isFresh is undefined. ;... invoke GetVariable, GV_hInstance ; returns the value of hInstance in eax. _________________ ... a professor saying: "use this proprietary software to learn computer science" is the same as English professor handing you a copy of Shakespeare and saying: "use this book to learn Shakespeare without opening the book itself. - Bradley Kuhn |
|||
|
20 Sep 2003, 20:16 |
|
|
JohnFound 20 Sep 2003, 20:32
So, maybe the Sizer control is not very good example, because it is created especially for Fresh, so it can use every global from Fresh without problem. Custom controls will not use every application defined global, because there is imposible to know what globals the user will create. The only problem IMHO will be with hInstance global. Because I want to make it to present in every project created with Fresh, IMO it's stupid to call GetModuleHandle everytime you need hInstance value. But you are right - we may simply export this value from Fresh and import the value in wrapper DLL, because wrapper DLL's are only for using in design-time by Fresh. They are not for using with compiled project in run-time.
Hm, maybe the problem is not as big as I though in the begining.
regards. [/list] |
|||
|
20 Sep 2003, 20:32 |
|
< Last Thread | Next Thread > |
Forum Rules:
|