 |
AutoHotkey Community
Let's help each other out
|
| View previous topic :: View next topic |
| What should happen to this project? |
| Let's work on it, I'll help |
|
11% |
[ 4 ] |
| Keep it alive |
|
85% |
[ 30 ] |
| Let it go |
|
0% |
[ 0 ] |
| I don't care |
|
2% |
[ 1 ] |
|
| Total Votes : 35 |
|
| Author |
Message |
majkinetor
Joined: 24 May 2006
Posts: 3626
Location: Belgrade
|
 Posted: Fri Jun 15, 2007 2:13 pm Post subject: |
 |
|
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 |
|
 |
majkinetor
Joined: 24 May 2006
Posts: 3626
Location: Belgrade
|
|
| Back to top |
|
|
majkinetor
Joined: 24 May 2006
Posts: 3626
Location: Belgrade
|
| Posted: Fri Jun 15, 2007 2:41 pm Post subject: |
|
|
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 |
|
|
majkinetor
Joined: 24 May 2006
Posts: 3626
Location: Belgrade
|
| Posted: Fri Jun 15, 2007 3:27 pm Post subject: |
|
|
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 |
|
|
toralf
Joined: 31 Jan 2005
Posts: 3842
Location: Bremen, Germany
|
| Posted: Fri Jun 15, 2007 3:33 pm Post subject: |
|
|
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 |
|
|
toralf
Joined: 31 Jan 2005
Posts: 3842
Location: Bremen, Germany
|
| Posted: Fri Jun 15, 2007 3:35 pm Post subject: |
|
|
| 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 |
|
|
majkinetor
Joined: 24 May 2006
Posts: 3626
Location: Belgrade
|
| Posted: Fri Jun 15, 2007 3:43 pm Post subject: |
|
|
| 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 |
|
|
majkinetor
Joined: 24 May 2006
Posts: 3626
Location: Belgrade
|
| Posted: Fri Jun 15, 2007 3:48 pm Post subject: |
|
|
| 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 3:52 pm; edited 1 time in total |
|
| Back to top |
|
|
toralf
Joined: 31 Jan 2005
Posts: 3842
Location: Bremen, Germany
|
| Posted: Fri Jun 15, 2007 3:50 pm Post subject: |
|
|
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 |
|
|
majkinetor
Joined: 24 May 2006
Posts: 3626
Location: Belgrade
|
| Posted: Fri Jun 15, 2007 3:54 pm Post subject: |
|
|
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 |
|
|
toralf
Joined: 31 Jan 2005
Posts: 3842
Location: Bremen, Germany
|
| Posted: Fri Jun 15, 2007 4:07 pm Post subject: |
|
|
| 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 |
|
|
majkinetor
Joined: 24 May 2006
Posts: 3626
Location: Belgrade
|
| Posted: Fri Jun 15, 2007 4:40 pm Post subject: |
|
|
| 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 4:42 pm; edited 1 time in total |
|
| Back to top |
|
|
toralf
Joined: 31 Jan 2005
Posts: 3842
Location: Bremen, Germany
|
| Posted: Fri Jun 15, 2007 4:40 pm Post subject: |
|
|
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 |
|
|
majkinetor
Joined: 24 May 2006
Posts: 3626
Location: Belgrade
|
| Posted: Fri Jun 15, 2007 4:52 pm Post subject: |
|
|
| 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 |
|
|
majkinetor!
Guest
|
| Posted: Fri Jun 15, 2007 5:24 pm Post subject: |
|
|
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 |
|
|
|
|
You can post new topics in this forum
You can reply to topics in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Register
Profile
Log in to check your private messages
Log in
