AutoHotkey Homepage AutoHotkey Community
Let's help each other out
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Lil Builder 0.7.1
Goto page Previous  1, 2, 3, 4 ... 16, 17, 18  Next
 
Reply to topic    AutoHotkey Community Forum Index -> Scripts & Functions
View previous topic :: View next topic  

What should happen to this project?
Let's work on it, I'll help
14%
 14%  [ 13 ]
Keep it alive
80%
 80%  [ 74 ]
Let it go
1%
 1%  [ 1 ]
I don't care
4%
 4%  [ 4 ]
Total Votes : 92

Author Message
majkinetor



Joined: 24 May 2006
Posts: 4511
Location: Belgrade
PostPosted: Fri Jun 15, 2007 1:13 pm    Post subject: Reply with quote
I tried another method to draw grid, much much simpler:

Code:
SetBatchLines, -1
#SingleInstance, force
   gui, +lastfound +Resize
   hGui := WinExist()

   GRID := 25

   gui, add, Button, hwndhLabel w100 h100, 123
   gui, show, w400 h500   

   dcMain := API_GetDC(hGui)

   hHor := API_LoadImage( 0, "hor.bmp", 0, 0, 0, 0x10 | 0x20)
   hVer := API_LoadImage( 0, "ver.bmp", 0, 0, 0, 0x10 | 0x20)

   memHor  := API_CreateCompatibleDC( dcMain )
   memVer  := API_CreateCompatibleDC( dcMain )
   API_SelectObject( memHor, hHor )
   API_SelectObject( memVer, hVer )

   OnMessage(WM_PAINT := 0x0F, "OnPaint")
   OnPaint("", "", "", hGui)

return

OnPaint(wparam, lparam, msg, hwnd){
   global

   if (hwnd != hGui)
      return
   
   SetTimer, PaintWindow, -10      ;protetct from spam
}

PaintWindow:
   WinGetPos, , , w, h, ahk_id %hGui%
   cntH := w/GRID, cntW := h/GRID
   

   i := 0  ;   i := rct_top
    loop, %cntW%
      API_BitBlt( dcMain, 0, i++*GRID, w, 1, memHor, 0, 0, 0xCC0020 )

   i := 0   ;      i := rct_left
    loop, %cntH%
      API_BitBlt( dcMain, i++*GRID, 0, 1, h, memVer, 0, 0, 0xCC0020 )
return

#include API_Draw.ahk


I have 2 bitmaps, Horizontal and Vertical
Horizontal bitmap is 1 pixel height and 1000 pixels width.
Vertical is 1000 pixels width, and 1 pixel height.

I construct grid by first gluing horizontal bitamps and then vertical ones.
Result is more sophisticated code, that seems to be of the same speed as ahkleaners. I measured with fooms QPC function and it results are similar, although Ahkleaners code tend to be somwhat faster which contradicts to what I have read on the net that drawing the line is slower then gluing the bitmaps....

So, currently, no benefits comparing to ahklearners code except if I didn't measure results correctly. It is somehow impossible to me that 2 dll calls in loop plus some extra overhead are the same speed as 1 ...
I think that GRID should be handled in WM_PAINT. It seems to work better with spam control.
_________________
Back to top
View user's profile Send private message
majkinetor



Joined: 24 May 2006
Posts: 4511
Location: Belgrade
PostPosted: Fri Jun 15, 2007 1:26 pm    Post subject: Reply with quote
Check out the GRID sample I was talking about here:

http://www.autohotkey.net/~majkinetor/-TEMP/grid.rar
_________________
Back to top
View user's profile Send private message
majkinetor



Joined: 24 May 2006
Posts: 4511
Location: Belgrade
PostPosted: Fri Jun 15, 2007 1:41 pm    Post subject: Reply with quote
Ok, I found much much faster method. No images are used, works faster then both previous solutions. This is entire script just execute it.

Code:
SetBatchLines, -1
#SingleInstance, force
   gui, +lastfound +Resize
   hGui := WinExist()

   GRID := 20
   OP := 0x42   ;blackness=0x42         ;WHITENESS=0xFF0062


   gui, add, Button, hwndhLabel w100 h100, 123
   gui, show, w400 h500   

   dcMain := API_GetDC(hGui)
   memDC  := API_CreateCompatibleDC( dcMain )



   OnMessage(WM_PAINT := 0x0F, "OnPaint")
   OnPaint("", "", "", hGui)

;   API_DeleteDC( tmpDC )

return

OnPaint(wparam, lparam, msg, hwnd){
   global
;   local i, w, h, cntW, cntH

   if (hwnd != hGui)
      return
   
   SetTimer, PaintWindow, -10      ;protetct from spam
}

PaintWindow:
   QPC()
   ;API_GetUpdateRect(hGui, "rct")

   ;Get the position of the builder window
   WinGetPos, , , w, h, ahk_id %hGui%
   cntH := w/GRID, cntW := h/GRID
   
   i := 0
    loop, %cntW%
      DllCall("BitBlt"
             , "uint",dcMain,"int", 0, "int", i++*GRID, "int", w, "int", 1
             , "uint",memDC, "int", 0, "int", 0  , "uint", OP)

   i := 0   ;      i := rct_left
    loop, %cntH%
      DllCall("BitBlt"
             , "uint",dcMain,"int", i++*GRID, "int", 0, "int", 1, "int", h
             , "uint",memDC, "int", 0, "int", 0  , "uint", OP)



   API_InvalidateRect(hLabel, 0, 0)
   tooltip % QPC()

return

;#include API_Draw.ahk

API_GetDC( hwnd ){
    return DllCall("GetDC", "uint", hwnd)
}


API_CreateCompatibleDC(hDC){
    return DllCall("CreateCompatibleDC", "uint", hDC)
}


API_InvalidateRect(hwnd, lpRect, bErase) {
     return DllCall("InvalidateRect", "uint", hwnd, "uint", 0, "uint", 1)
}

API_CreateCompatibleBitmap( hdc , nWidth, nHeight ) {
    return DllCall("CreateCompatibleBitmap", "uint",hdc, "int", nWidth, "int",nHeight)
}



InsertInteger(pInteger, ByRef pDest, pOffset = 0, pSize = 4)
; The caller must ensure that pDest has sufficient capacity.  To preserve any existing contents in pDest,
; only pSize number of bytes starting at pOffset are altered in it.
{
    Loop %pSize%  ; Copy each byte in the integer into the structure as raw binary data.
        DllCall("RtlFillMemory", "UInt", &pDest + pOffset + A_Index-1, "UInt", 1, "UChar", pInteger >> 8*(A_Index-1) & 0xFF)
}

ExtractInteger(ByRef pSource, pOffset = 0, pIsSigned = false, pSize = 4)
; pSource is a string (buffer) whose memory area contains a raw/binary integer at pOffset.
; The caller should pass true for pSigned to interpret the result as signed vs. unsigned.
; pSize is the size of PSource's integer in bytes (e.g. 4 bytes for a DWORD or Int).
; pSource must be ByRef to avoid corruption during the formal-to-actual copying process
; (since pSource might contain valid data beyond its first binary zero).
{
    Loop %pSize%  ; Build the integer by adding up its bytes.
        result += *(&pSource + pOffset + A_Index-1) << 8*(A_Index-1)
    if (!pIsSigned OR pSize > 4 OR result < 0x80000000)
        return result  ; Signed vs. unsigned doesn't matter in these cases.
    ; Otherwise, convert the value (now known to be 32-bit) to its signed counterpart:
    return -(0xFFFFFFFF - result + 1)
}

QPC()
{
    Static QPCLAST, QPCNOW, QPCFREQ

    if not QPCFREQ
        if not DllCall("QueryPerformanceFrequency", "Int64 *", QPCFREQ)
            return "Fail QPF"

    QPCLAST=%QPCNOW%
    if not DllCall("QueryPerformanceCounter", "Int64 *", QPCNOW)
        return "Fail QPC"

    return (QPCNOW-QPCLAST)/QPCFREQ
}


U can make grid any color, by adding one FillRect at the start. Its important to note that this is all done only once, at startup or when user change color. Drawing is always the same. For now you can test white grid by chaning OP param
_________________
Back to top
View user's profile Send private message
majkinetor



Joined: 24 May 2006
Posts: 4511
Location: Belgrade
PostPosted: Fri Jun 15, 2007 2:27 pm    Post subject: Reply with quote
I updated the LilBuilder code with new grid approach so you can check it out in action

http://www.autohotkey.net/~majkinetor/-TEMP/LilBuilder_v0.6.5.rar

2toralf
As you were the one to merge this with the project, can you please remove all references to Grid_Draw function and add OnPain event they way I demonstrated in above script. I wanna see how that works before deducing which mechanism to use.
_________________
Back to top
View user's profile Send private message
toralf



Joined: 31 Jan 2005
Posts: 3910
Location: Bremen, Germany
PostPosted: Fri Jun 15, 2007 2:33 pm    Post subject: Reply with quote
I tried it. It is nice and simple, and controls should be easy to exclude, but will slow down the drawing when mayn controls are used. I didn't managed to specif different colors though. Only black and white.

Insert/ExtractInteger() functions are not used.
_________________
Ciao
toralf
Back to top
View user's profile Send private message Send e-mail Visit poster's website
toralf



Joined: 31 Jan 2005
Posts: 3910
Location: Bremen, Germany
PostPosted: Fri Jun 15, 2007 2:35 pm    Post subject: Reply with quote
majkinetor wrote:
can you please remove all references to Grid_Draw function and add OnPain event they way I demonstrated in above script. I wanna see how that works before deducing which mechanism to use.
Yes I can, but what is the difference then to your code you just posted?
Should I now merge or implement your way myself?
_________________
Ciao
toralf
Back to top
View user's profile Send private message Send e-mail Visit poster's website
majkinetor



Joined: 24 May 2006
Posts: 4511
Location: Belgrade
PostPosted: Fri Jun 15, 2007 2:43 pm    Post subject: Reply with quote
Quote:
Yes I can, but what is the difference then to your code you just posted?


The difference is that I think with spam control results will be more fluid (when we speak about drawing on top of controls). For instance WM_PAINT is not sent when you shrink window, while now GRID_Draw() is called for shrinking the window too. This makes short drawing of grid over controls of lesser frequency, thus form looks better.

The diffference is also maintability, as you have grid on one place.

You can not currently set color except black and white. I dont' know why commented code that should handle this doesn't work... will check it out more. But white is very nice IMO with default GUI color.

BTW, I updated the code again. I fixed Properties so it doesn't spam with msgbox if you click on it, and it keeps the position you last put it. All changes are in inc\Properties.ahk. I think that this file should have another name as this is the prefix for PGUI. Perhaps I should change Properties wrapper to be named PGUI.

http://www.autohotkey.net/~majkinetor/-TEMP/LilBuilder_v0.6.5.rar

BTW, something is reactivating PGUI again and I don't know why.. it shouldnt be active window unless you click it. Perhaps some of the owner stuff mess it... If you have time, please examine this.
_________________
Back to top
View user's profile Send private message
majkinetor



Joined: 24 May 2006
Posts: 4511
Location: Belgrade
PostPosted: Fri Jun 15, 2007 2:48 pm    Post subject: Reply with quote
Quote:
, but will slow down the drawing when mayn controls are used.


Yes, controls are iterated and repainted all.... I am looking the way to solve this... GetUpdateRegion didn't help so far or I didn't do something right...

I think WM_PAINT might solve those problems
_________________


Last edited by majkinetor on Fri Jun 15, 2007 2:52 pm; edited 1 time in total
Back to top
View user's profile Send private message
toralf



Joined: 31 Jan 2005
Posts: 3910
Location: Bremen, Germany
PostPosted: Fri Jun 15, 2007 2:50 pm    Post subject: Reply with quote
To the above post: Please do all the chnages you feel necessary. I haven't done any coding, so I will just put your final code into the repo.


To a previous post
majkinetor wrote:
I am also trying to make Properties not be activated when it is shown, just when explicitely activated (I don't want it to steal focus from User gui)
Maybe you can use "NA" for Gui,Show
_________________
Ciao
toralf
Back to top
View user's profile Send private message Send e-mail Visit poster's website
majkinetor



Joined: 24 May 2006
Posts: 4511
Location: Belgrade
PostPosted: Fri Jun 15, 2007 2:54 pm    Post subject: Reply with quote
In latest code Properties_Show is called only when you close Properties window. So, Gui, Show is not called. I wonder what makes PGUI focused.

Quote:
I haven't done any coding, so I will just put your final code into the repo.

I think we should see how WM_PAINT works first. I will try more during the veekend, until then its not necessary to update the code. Thi s is still experiment...

You can see in my above example that button on the form doesn't flicker much when you do things with the form... Not as much as controls in LilBuilder now.
_________________
Back to top
View user's profile Send private message
toralf



Joined: 31 Jan 2005
Posts: 3910
Location: Bremen, Germany
PostPosted: Fri Jun 15, 2007 3:07 pm    Post subject: Reply with quote
majkinetor wrote:
We must start to organise object properties. Public properties.
Yes, I think that is needed, Otherwise we end up in a mess.

majkinetor wrote:
The list would be good for start. We can have common properties (like x, y, w, h) and object private properties.

I wouldn't put X/Y/W/H into properties, since they would require too often an update. It is fine to grep them from the gui on export or when info is requested, e.g. now with tooltip.
I tried to show control positions in my old version of SGUI and it slowed down a lot. The pure values are not very important as long as the gui looks nice and can be easily manipulated in the user gui. And I assume it is possible now with the implemented alignment, incremental movement/resize.

majkinetor wrote:

Common properties:
Code:
Style : Button 
Color:  TColors (global Properties type, ComboBox)
Visible: TBool (true/false ComboBox)
Font   : Button
Color is not a common prop for controls. E.g. Buttons don't obey this and some other IIRC. But Anchor is common (except for Statusbar)
TBool should be a Checkbox, not a ComboBox

majkinetor wrote:
Text:
Code:
[Text]
Multiline :TBool
Multiline is also something that is done by resizing. I wouldn't use it for properties.

majkinetor wrote:
Lets check out GUI. It will be something like
Code:

[Gui]
Style : TGuiStyle (Combo : ToolWindow, NoCaption... )
Position: TGuiPosition (Combo: Design, Center... )
State: TGuiState (minimised, maximized, hidden)
Style and State have several values that can be used in any combination. Thus is makes no sense to have them in a single combobox.
I do not understand what is ment with Position.

majkinetor wrote:
moving control should change its position and size properties
Please no, see above.

majkinetor wrote:
I realised that PGui is good for debuging too as we currently have no mean to see what is going on with global variables as they are in dicts.
That's what I currently use it for too.

majkinetor wrote:
some properties we don't want to present in design mode (for instance Visibile). So property will need to have another attribute (InDesign= true/false)
Why? They are just not applied, only stored and used for export and final script.

majkinetor wrote:
- Suggestions and different approaches are appricated ofc.
That's what I tried.
_________________
Ciao
toralf
Back to top
View user's profile Send private message Send e-mail Visit poster's website
majkinetor



Joined: 24 May 2006
Posts: 4511
Location: Belgrade
PostPosted: Fri Jun 15, 2007 3:40 pm    Post subject: Reply with quote
Quote:
I wouldn't put X/Y/W/H into properties, since they would require too often an update.

I understand, but every form designer have this. Sometimes its more appealing to set position via properties then by mouse.

Quote:
I tried to show control positions in my old version of SGUI and it slowed down a lot.

Perhaps we can solve speed problems. Perhaps not. I think we should implement size & pos with everyhing else and comment it if it turns out to be slow...

Quote:
But Anchor is common

GUI doesn't have Anchor too

Quote:
I do not understand what is ment with Position.

Every IDE has this - you don't necesseraly want to show the GUI on the same position that you use for design.

Quote:
Why? They are just not applied,

Because we will not have special cases. Its better to treat all properties the same and check some flags to see special actions. Anyway, property is object per se (looking from OO perspective) and is it applied or not is its property.

Quote:
Style and State have several values that can be used in any combination

Yea, for this kind of property I was counting on Button (button = has property editor)
_________________


Last edited by majkinetor on Fri Jun 15, 2007 3:42 pm; edited 1 time in total
Back to top
View user's profile Send private message
toralf



Joined: 31 Jan 2005
Posts: 3910
Location: Bremen, Germany
PostPosted: Fri Jun 15, 2007 3:40 pm    Post subject: Reply with quote
These would be two general functions to apply props
Code:
Control_ApplyProp(GuiHWND, CtrlHWND, SubCommand, Param3 = ""){
  GuiID := Gui(GuiHWND, "GuiID")
  CtrlID := Control(CtrlHWND, "VarName")
  GuiControl, %GuiID%:%SubCommand%, %CtrlID%, %Param3%
}

Gui_ApplyProp(GuiHWND,Option, Param = ""){
  GuiID := Gui(GuiHWND, "GuiID")
  Gui, %GuiID%:%Option%, %Param%
}


2maj: Could you please tell me how you want the data flow to be organized? Will there still be context menu? I hope, since that eases a lot of handling and is very fast.
I assume the data flow to be this: If user changes a prop in the PGUI or if he selects in the context menu, both call the same function to set that prop. This SET function stores the value in dic and applies to ctrl/gui if possible. After that PGUI gets updated. Right?
That either requires dyn function calls, or additional subroutines or a long if/else list to call the correct function. Since I do not know when dyn function calls get implemented I guess additional subroutines are the way to go, since they are easy to maintain, even though they are ugly.
Code:
DoThis:
  Dothis()
Return
DoThis(){
}
This will also allow to replace them later easily when dyn function calls get added.
_________________
Ciao
toralf
Back to top
View user's profile Send private message Send e-mail Visit poster's website
majkinetor



Joined: 24 May 2006
Posts: 4511
Location: Belgrade
PostPosted: Fri Jun 15, 2007 3:52 pm    Post subject: Reply with quote
Quote:
Will there still be context menu?

Yeh, I told you , context menu is shortcut/convenince for PGUI.

Quote:
If user changes a prop in the PGUI or if he selects in the context menu, both call the same function to set that prop.


Exactly. Check this out for example: Button label position. NOw its in the menu. As this is button property, the prime method to set it is PGUI. Lets say we name it LabelPos of type ComboBox having 3 values (left, middle, center). When user selects left from the list, PGUI signals event and we call appropriate function/sub, lets say Button_LabelPos( "left" ). This function does the job.

Now, talking about menu, it becomes very simple. Just some hardoced properties. Lets say button has only 3 items in context menu, left, middle, center. This is its context menu then:

Code:
OnMenuClick:
     Button_LabelPos(A_ThisMenuItem)
return
       


We will have to use subrotines for now, or Laslzos workaround. BUt since second use message, I afraid to use it. So, sub is way to go. We will "convert it to function" just the way u described but with param

DoThis:
Dothis( Properties_GetValue(..) )
Return

DoThis(value){
}

The problem is that we need one sub wrapper for each property which is bad. So, I think plain subs with 1 or 2 globals is the way to go, for simplicity reasons. We will change this later, anyway, dyn calls will surely come, its just question when...
_________________
Back to top
View user's profile Send private message
majkinetor!
Guest
PostPosted: Fri Jun 15, 2007 4:24 pm    Post subject: Reply with quote
What we talked so far is nice, but I have 1 fear - how will we export all that. We can use the same setter functions in exported version, but then all those setters have to be included in final script. We may get large scripts that way....

Well, we are slowely exiting ahk purpose... I hope everything will turn out to be fine, but AHK is indeed not ment for projects like this.
Back to top
Display posts from previous:   
Reply to topic    AutoHotkey Community Forum Index -> Scripts & Functions All times are GMT
Goto page Previous  1, 2, 3, 4 ... 16, 17, 18  Next
Page 3 of 18

 
Jump to:  
You can post new topics in this forum
You can reply to topics in this forum


Powered by phpBB © 2001, 2005 phpBB Group