flat assembler
Message board for the users of flat assembler.

flat assembler > IDE Development > Fresh controls design time information specification.

Author
Thread Post new topic Reply to topic
JohnFound



Joined: 16 Jun 2003
Posts: 3494
Location: Bulgaria
IMPORTANT
Read and comment please:

[EDIT] Outdated info. Deleted because of big size. Look below. [/EDIT]


Last edited by JohnFound on 20 Sep 2003, 19:30; edited 2 times in total
Post 20 Sep 2003, 15:40
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3494
Location: Bulgaria
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
Post 20 Sep 2003, 15:44
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
scientica
Retired moderator


Joined: 16 Jun 2003
Posts: 689
Location: Linköping, Sweden
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
Post 20 Sep 2003, 16:03
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3494
Location: Bulgaria
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. Smile 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.
Post 20 Sep 2003, 16:28
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
scientica
Retired moderator


Joined: 16 Jun 2003
Posts: 689
Location: Linköping, Sweden
[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
Post 20 Sep 2003, 18:07
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3494
Location: Bulgaria
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:

Code:
.........
        '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'
    


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.
Post 20 Sep 2003, 18:42
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3494
Location: Bulgaria
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. Sad

[edit]Outdated attachment removed[/edit]


Last edited by JohnFound on 12 Oct 2003, 15:13; edited 1 time in total
Post 20 Sep 2003, 19:08
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
scientica
Retired moderator


Joined: 16 Jun 2003
Posts: 689
Location: Linköping, Sweden
Great Smile
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 (Laughing Wink) 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
Post 20 Sep 2003, 20:16
View user's profile Send private message Visit poster's website MSN Messenger ICQ Number Reply with quote
JohnFound



Joined: 16 Jun 2003
Posts: 3494
Location: Bulgaria
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. Smile

regards.

[/list]
Post 20 Sep 2003, 20:32
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2019, Tomasz Grysztar.

Powered by rwasa.