 |
AutoHotkey Community Let's help each other out
|
| View previous topic :: View next topic |
| Author |
Message |
Rajat
Joined: 28 Mar 2004 Posts: 1718
|
Posted: Thu May 31, 2007 11:29 pm Post subject: |
|
|
@corrupt
besides what the modern editors already provide, a gui editor and some functions provided by scripts here, what extra do you envision in an IDE ?... the only big thing that comes to my mind is a debugger. _________________
 |
|
| Back to top |
|
 |
corrupt
Joined: 29 Dec 2004 Posts: 2421
|
Posted: Fri Jun 01, 2007 1:14 am Post subject: |
|
|
| Rajat wrote: | @corrupt
besides what the modern editors already provide, a gui editor and some functions provided by scripts here, what extra do you envision in an IDE ?... the only big thing that comes to my mind is a debugger. | Although I hesitate to mention it (incoming flaming expected...), I would suggest something similar in concept to the IDE in VB6, Envelop, and similar languages where you have a window for code where the code is separated by section, function, etc... and can be selected by drop down lists. This way the IDE decides where to place the code for each GUI control, event triggers (OnMessage, g-labels, etc...), user functions, labels, etc... and everything is neatly organized and quickly accessible for the user. The next time the code is loaded, the IDE will know where everything is and know which sections to ignore... |
|
| Back to top |
|
 |
Rajat
Joined: 28 Mar 2004 Posts: 1718
|
Posted: Fri Jun 01, 2007 1:33 am Post subject: |
|
|
whoa!  _________________
 |
|
| Back to top |
|
 |
mwharri
Joined: 15 Mar 2007 Posts: 70
|
Posted: Fri Jun 01, 2007 3:10 am Post subject: |
|
|
| corrupt wrote: | | Although I hesitate to mention it (incoming flaming expected...), I would suggest something similar in concept to the IDE in VB6, Envelop, and similar languages where you have a window for code where the code is separated by section, function, etc... and can be selected by drop down lists. This way the IDE decides where to place the code for each GUI control, event triggers (OnMessage, g-labels, etc...), user functions, labels, etc... and everything is neatly organized and quickly accessible for the user. The next time the code is loaded, the IDE will know where everything is and know which sections to ignore... |
That's pretty heavy.
Proof of Concept for the RaGrid Control Properties Gui:
http://www.autohotkey.net/~mwharri/ragrid.zip
Function used to build Grid Control(nothing special):
| Code: | fileName = %A_ScriptDir%\DefaultControlProperties.xml ; Control Properties
control = Edit ; control in focus on the builder
controlClass := %control%1 ; ClassNN of the control (thinking ahead:
cX = 69 ; gui-xml file will probably be indexed by classnn)
cY = 71
cW = 70
cH = 68
FillPropertiesGridWithDefaults(controlClass, control, fileName, cX, cY, cW, cH)
FillPropertiesGridWithDefaults(controlClass, control, fileName, cX="", cY="", cW="", cH="") {
global
Gui, +LastFound +Resize
hwnd := WinExist()
RG_Init()
hGrd := RG_Add(hwnd, 0, 0, 300, 800, STYLE_VGRIDLINES | STYLE_GRIDLINES )
RG_AddColumn(hGrd, "cap=Property", "w=150", "ha=2", "ca=2" )
RG_AddColumn(hGrd, "cap=Value", "w=150", "ha=1", "ca=1")
RG_SetFont(hGrd, "s10 bold, Arial")
RG_SetColors(hGrd, "B1 GFFFFFF TFFFFFF")
Loop 99
{
index := A_Index - 1
property := XMLRead(fileName, "controls.Generic.name(" . index . ")", "")
if property =
break
value := XMLRead(fileName, "controls.Generic.default(" . index . ")", "")
if property = y
value = %cY%
if property = x
value = %cX%
if property = h
value = %cH%
if property = w
value = %cW%
aCol1 := property, aCol2 := value, RG_AddRow(hGrd, aCol)
}
Loop 99
{
index := A_Index - 1
property := XMLRead(fileName, "controls." . control . ".name(" . index . ")", "")
if property =
break
value := XMLRead(fileName, "controls." . control . ".default(" . index . ")", "")
aCol1 := property, aCol2 := value, RG_AddRow(hGrd, aCol)
}
RG_SetHdrHeight(hGrd, 30)
RG_SetRowHeight(hGrd, 22)
Gui, Show, h800 w300, %control% Control Properties Dialog
} |
Is there a better way to do this? I pretty much just taught myself how to work with XML so I could put this together. There's still much to work on, as I only have properties set up for Button, Text, and Edit Controls. Among many other things. Wrappers for custom controls will have to be completed before that could every be implemented.
Assumptions and constraints would have to be made using this approach. Each gui will probably have to reside in it's own script file, and an accompanying xml file will also have to be made for each gui.
This could arguably enforce a type of code standardization. Wrapping a function or subroutine around the generated gui code would also create another type of code standardization.
Ensuring that the generated code always matches the xml file would be a challenge. Manually changing any of the code outside the IDE would cause the the xml's properties and the code to translate 2 different things.
I could go on and on and on and on I'm sure....
Comments? |
|
| Back to top |
|
 |
toralf
Joined: 31 Jan 2005 Posts: 3841 Location: Bremen, Germany
|
Posted: Fri Jun 01, 2007 8:26 am Post subject: |
|
|
I tested the version 0.04 (waiting for 007 :) of your Lil' Builder. The handling is nice and the code for it is small. That is perfect.
There are some things though that still need to be solved:
- Movement of the gui and toolbar are not possible (fairly simple to fix by commenting line 23 and 24)
- After adding a tab, user should be able to add more tab pages and populate them individualy. I guess using MMenu this could be done, since the RButton is not use yet.
- movement and resize controls in grid jumps (that is easy, though might introduce flicker)
- selection of multiple controls (either with Ctrl+Click or by draging a selection frame)
- manipulating multiple controls: align, set to same resize, distribute (once a list of controls is created by selection, this is easy)
- creating/manipulating multiple windows in parallel
- when you look at number of global vars, it already gets scary now. I do not want to think of the problems that will arise when properties are used for guis and controls. A naming convention should be used, or better most of the vars should be made local, via specific container functions with static variables or via a/some dictionary/ies.
Looking at the code I found some, small items:
Line 82 should say: | Code: | | caption := txt " Control " User_ctrlCnt |
The subroutine User_Close should have a "ExitApp" at line 223
If maj could split the one file into separate but logical files, we could start to work on it as a team at least contribute to certain parts/files. The easiest would be if someone could set up an SubVersion server, but I guess that this is out of reach (do not want to use Sourceforge for such a small project) _________________ Ciao
toralf  |
|
| Back to top |
|
 |
majkinetor
Joined: 24 May 2006 Posts: 3644 Location: Belgrade
|
Posted: Fri Jun 01, 2007 8:27 am Post subject: |
|
|
You are totaly right mwharri. Acctually all are totaly right, except Laszlo. I understand, Laszlo, that wish to use your own editor is high, but no IDE alows for that, and the things you mention will be certanly implemented at some point (column selection is at to do list for HiEdit, every hotkey can be customizable...) if we do the AHK IDE job.
| corrupt wrote: | | Although I hesitate to mention it (incoming flaming expected...), I would suggest something similar in concept to the IDE in VB6, Envelop |
Yes, it is heavy. This requires in detail design before any code is written.
| mwharri wrote: | | Assumptions and constraints would have to be made using this approach. Each gui will probably have to reside in it's own script file, and an accompanying xml file will also have to be made for each gui. |
True. For instance, my plan was to have export as GUINAME_Create() function. This function will contain array of Gui, Add commands and friends. I was thinking the same for setting the initial values : GUINAME_Init(), and this one would contain set of control modifying commands (to set button labeles, fill default lines in Edits, TVs, LV's...). This is a little slower then specifying those things on creation but its more flexibile and this is exactly how dotNet handle things starting from version 2. There is so called partial class which means that class definition is maintained across multiple files (previosly only 1 file was possible per class). VS on its own when you create GUIs and add properties and events create things in its own class part that it calls FormName_design.cs. This one contains things like
| Quote: | Buton1.Caption = "bla bla"
Form1.OnClose = Form1_OnClose |
and although you can mess with this , if you don't do it following the "VS designer standard" you will screw things up.
Another good thing about "export by functions" is that functions can be easily extracted from the code using RegExp (code already exists), so it will be easy enough to reserve names for elements important for IDE and modify func bodies. This IDE generated functions should have its own AHK file (the same as in VS) and the resulting AHK script will be in 2 parts - user part & IDE part, user part to be main, and IDE part to be included in user part.
So, this basicly means standardisation of many things in AHK code writting, which byitself doesn't have to be nor good nor bad. It depends on how we design the whole thing.
| mwharri wrote: | Proof of Concept for the RaGrid Control Properties Gui
...
Is there a better way to do this? I |
Full blown properties editor will have to be encapsulated the same way as for instance HotKeyGui or HexView. We should create API for it but first RaGrid should be totaly wrapped. It supports things required by Properties WIndow - your work shows us just 2 columns, second one to be all in edits. In Reality, second column contains more data types: edit (enter value yourself), combobox (enumeration of values), checkboxes (similar as combobox with 2 values - true, false), buttons (to open property builders where previous is not enough). Check out this demo of RaGrid to see posibilities
http://www.autohotkey.net/~majkinetor/-TEMP/GridDemo.exe
All in all, I will see to wrap RaGrid in full as I was the one to start that. _________________
 |
|
| Back to top |
|
 |
SKAN
Joined: 26 Dec 2005 Posts: 6223
|
Posted: Fri Jun 01, 2007 8:36 am Post subject: |
|
|
| majkinetor wrote: | | All in all, I will see to wrap RaGrid in full as I was the one to start that. |
Thanks!  |
|
| Back to top |
|
 |
majkinetor
Joined: 24 May 2006 Posts: 3644 Location: Belgrade
|
Posted: Fri Jun 01, 2007 8:46 am Post subject: |
|
|
| toralf wrote: | | Movement of the gui and toolbar are not possible (fairly simple to fix by commenting line 23 and 24) |
Not such limitation. It is fixed in almost all IDEs (not in Delphi). I did it as I didn't want to mess with hiding the selector at this point. Now, when you click the User Gui, selector is simply hidden by going bellow the User window in Z-order The good side effect of selector not being part of User Gui (I first tried SetParent but didn't work correctly) is that you are able to see controls going out of boundaries of parent window.
| Quote: | | After adding a tab, user should be able to add more tab pages and populate them individualy. I guess using MMenu this could be done, since the RButton is not use yet. |
This must be well thought out - adding controls to tabs instead guis.. didn't thought out solution yet for this, but I think we can postpone that for the very end.
MMenu as context menu is indeed planned. MMenu should fit perfectly here as of non-dynamic usage
| Quote: | | movement and resize controls in grid jumps (that is easy, though might introduce flicker) |
This is a bit problematic for me. If anybody can do this or have idea it would be good. I succeedd to write something that work more or less nice with resizing although this will require to monitor WM_SYSCOMMAND and scan which resizing method out of 8 is used (currently there is no difference, when user resize selector GUI I just realign selector's current control (Selector_controlID) to match selector position, size. To handle grid movement in all directions (I did it for 3 directions - right, down, rightdown) I have to know which of 8 methods is currently in action via WM_SYSCOMMAND monitoring.
The problem with moving and grid is of another kind. You see, control is moved AFTER you releise the selector. I planned for it to be moved all the time while you hover with selector around. But this doesn't work. Relevant code part is :
| Code: | OnMouseMove(wparam, lparam, msg, hwnd) {
global
if (hwnd = Selector_hwnd) and GetKeyState("LButton"){
SendMessage, 0x112,0xF012,0,,ahk_id %Selector_hwnd% ; [ WM_SYSCOMMAND, SC_MOVE ]
Selector_UpdateCtrl()
}
} |
The problem is RED code never gets executed until you releise the mouse. I don't understand why, but that is again one of those messages mumbo jumbo that I experience so far only in AHK. Acctually, any other code doesn't run, (place Tooltip instead Selector_UpdateCtrl) and the GRID code would have to be put here.
So, any ideas, code or whatever for GRID moving is highly appriciated.
I was thinking to remove SendMessage method to move the selector and use somethin else, as this is probably creating a problem - another message arrives while in message handler.
| Quote: | - selection of multiple controls (either with Ctrl+Click or by draging a selection frame)
- manipulating multiple controls: align, set to same resize, distribute (once a list of controls is created by selection, this is easy)
- creating/manipulating multiple windows in parallel
|
This shouldn't be very hard.
| Quote: | | when you look at number of global vars, it already gets scary now. I do not want to think of the problems that will arise when properties are used for guis and controls. A naming convention should be used, or better most of the vars should be made local, via specific container functions with static variables or via a/some dictionary/ies. |
Those globals are not of LilBuilder. Lil uses couple of globals only.
Others are of custom controls. With better custom controls wrappers this will dissapear. THey are created per se, not as part of LilBuilder project. _________________

Last edited by majkinetor on Fri Jun 01, 2007 8:58 am; edited 3 times in total |
|
| Back to top |
|
 |
majkinetor
Joined: 24 May 2006 Posts: 3644 Location: Belgrade
|
Posted: Fri Jun 01, 2007 8:52 am Post subject: |
|
|
Oh, predators on the site, searching for its own food
(just kiddin Skan) _________________
 |
|
| Back to top |
|
 |
toralf
Joined: 31 Jan 2005 Posts: 3841 Location: Bremen, Germany
|
Posted: Fri Jun 01, 2007 8:57 am Post subject: |
|
|
I'm back on Lil' Builder:
The idea to use a gui as a selector is great, since it allows to use the resize arrows.
In line 176, I would set the timer to negative (-500), since it only needs to be updated once.
I guess line 235 should be
Why do you use TopChild(pParent, pHwnd)? _________________ Ciao
toralf  |
|
| Back to top |
|
 |
toralf
Joined: 31 Jan 2005 Posts: 3841 Location: Bremen, Germany
|
Posted: Fri Jun 01, 2007 9:05 am Post subject: |
|
|
| majkinetor wrote: | The problem is RED code never gets executed until you releise the mouse. I don't understand why, but that is again one of those messages mumbo jumbo that I experience so far only in AHK. Acctually, any other code doesn't run, (place Tooltip instead Selector_UpdateCtrl) and the GRID code would have to be put here.
So, any ideas, code or whatever for GRID moving is highly appriciated.
I was thinking to remove SendMessage method to move the selector and use somethin else, as this is probably creating a problem - another message arrives while in message handler.
| One solution could be to apply the GRID on the Selector gui only. But might introduce flicker.
Another solution could be to start a timer in the case GRID is used. The timer updates the control. _________________ Ciao
toralf  |
|
| Back to top |
|
 |
majkinetor
Joined: 24 May 2006 Posts: 3644 Location: Belgrade
|
Posted: Fri Jun 01, 2007 9:06 am Post subject: |
|
|
| Quote: | | Why do you use TopChild(pParent, pHwnd)? |
Some controls have its own children, like ComboBox, HiEdit, ListView, RaGrid, etc.
Without TopChild, you can grab some of their controls and move them around (this was funny side effect of prevous versions). So, I could took for instance HiEdit scrollbar and put it in the middle of HiEdit control.
Without this, combobox was possible to select only if you clicked the arrow as otherwise, edit that is contained in combox was getting the attention...
| Quote: | | In line 176, I would set the timer to negative (-500), since it only needs to be updated once. |
Yeah, we can do that now. This value can be tweaked for more fluid update. Initialy it was called every time, but its a bit overkill.
Yes, copy/pasting without enough concentration.
| Quote: | One solution could be to apply the GRID on the Selector gui only. But might introduce flicker.
Another solution could be to start a timer in the case GRID is used. The timer updates the control. |
I will post you how it looks so far.
There is a new global GRID set to 30
The new code is this for now:
| Code: | Selector_Size:
if (GRID) {
WinGetPos, ux, uy,,, ahk_id %User_hwnd%
MouseGetPos, mx, my
Selector_UpdateCtrlSize(mx-ux, my-uy+TITLEHEIGHT)
}
else Selector_UpdateCtrl()
return
Selector_UpdateCtrlSize(mx="", my="") {
local sw, sh, cx, cy, cw, ch
if !mx {
WinGetPos,,,sw,sh, ahk_id %Selector_hwnd%
ControlMove,,,, sw, sh, ahk_id %Selector_ctrlId%
SetTimer, User_Refresh, 500
return
}
ControlGetPos, cx,cy,,,,ahk_id %Selector_ctrlId%
tooltip %Selector_ctrlId%
cw := (mx//GRID)*GRID - cx
ch := (my//GRID)*GRID - cy + TITLEHEIGHT
ControlMove,,,,cw,ch, ahk_id %Selector_ctrlId%
} |
Red code is not used for now, it was intended that I pass no values to the function if I want not to use the GRID...
The whole script (just overwrite over old, backup old)
| Code: | ;By majkinetor
; v0.04
SetBatchLines -1
SetControlDelay, -1
#SingleInstance force
CoordMode, Mouse, Screen
Toolbox_GUI := 1
Selector_GUI:= 2
User_GUI := 3
GRID := 30
SysGet TITLEHEIGHT, 31
TITLEHEIGHT += 4
Dock_ClientID := ToolBox_Create()
Show("Toolbox", -1000, 0, 0, 0)
Dock_HostId := User_Create()
Show("User", "", "", 550, 610)
Selector_Create()
DisableWindowMoving(User_hwnd)
DisableWindowMoving(Toolbox_hwnd)
SetMessageHandlers( true )
Dock(0,-1,-10, 0,0,0, 0,130, 0,665) ; left, top
Dock_Update(Dock_HostId) ; :D
Hotkey, IfWinActive, ahk_id %Selector_hwnd%
Hotkey, DEL, Selector_OnDelete
return
Toolbox_Create() {
global
Gui %Toolbox_GUI%:Font, bold
gui %Toolbox_GUI%:+LastFound +ToolWindow +LabelToolbox_
gui %Toolbox_GUI%:add, Text, x5, AHK controls
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Std\Text.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Std\Edit.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Std\ComboBox.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Std\Button.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Std\CheckBox.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Std\Radio.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Std\Picture.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Std\ListBox.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Std\ListView.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Std\TreeView.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Std\Tab.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Std\HotKey.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Std\Groupbox.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Std\DateTime.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Std\MonthCal.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Std\Progress.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Std\UpDown.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Std\Slider.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Std\StatusBar.png
gui %Toolbox_GUI%:add, Text, y+20, Custom controls
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Cst\HiEdit.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Cst\HLink.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Cst\RaGrid.png
gui %Toolbox_GUI%:add, Picture, gToolbox_OnClick ,res\Cst\IE.png
Toolbox_Std := "Text,Edit,ComboBox,Button,CheckBox,Radio,Picture,ListBox,ListView,TreeView,Tab,HotKey,GroupBox,DateTime,MonthCal,Progress,UpDown,Slider,StatusBar"
return (Toolbox_hwnd := WinExist())
}
Toolbox_OnClick() {
local caption, txt, ux, uy, customCtrl := false
User_ctrlCnt++
GuiControlGet, txt, %Toolbox_GUI%: , %A_GuiControl%
SplitPath, txt, ,,,txt
if txt not in %Toolbox_Std%
customCtrl := true
caption := "New Control " cnt
if txt = Picture
caption := A_WinDir "\Notepad.exe"
if !customCtrl {
Gui, %User_GUI%:Add, %txt%, x0 y0 vNew%User_ctrlCnt% HWNDID%User_ctrlCnt%, %caption%
Selector_ctrlId := ID%User_ctrlCnt%
}
else {
if txt = HiEdit
Selector_ctrlId := HE_Add( User_hwnd, 0, 0, 300, 200)
if txt = HLink
Selector_ctrlId := HLink_Add( User_hwnd, "Click <a href=""http://www.Google.com"">here</a>", 0, 0, 80, 20)
if txt = RaGrid
{
RG_Init()
Selector_ctrlId := RG_Add(User_hwnd, 0, 0, 220, 150, STYLE_VGRIDLINES | STYLE_GRIDLINES )
RG_AddColumn(Selector_ctrlId, "cap=Col1", "w=150" )
RG_AddColumn(Selector_ctrlId, "cap=Col2", "w=50")
RG_SetHdrHeight(Selector_ctrlId, 25)
}
if txt = IE
{
pwb := IE_Add( User_hwnd, 0, 0, 200, 200)
IE_LoadHTML(pwb, "<a href=""http://www.autohotkey.com/forum/viewtopic.php?t=19225&start=0"">IE Control</a>")
}
}
WinGetPos, ux, uy,,, ahk_id %User_hwnd%
MouseMove, ux+12, uy+TITLEHEIGHT+8
Selector_Set2Ctrl()
Send {LButton down}
}
Toolbox_OnClick:
Toolbox_OnClick()
return
OnMouseDown(wparam, lparam, msg, hwnd){
local ha, hCtrls
ha := DllCall("GetAncestor", "uint", hwnd, "uint", 2)+0 ;get gui handle [ GA_ROOT ]
if (ha = User_hwnd) {
Selector_ctrlId =
MouseGetPos, ,,, hCtrl, 2
if (hCtrl != "") {
Selector_ctrlId := TopChild(ha, hCtrl)
Selector_Set2Ctrl()
return 0
}
}
}
TopChild(pParent, pHwnd) {
h := pHwnd
loop {
hp := DllCall("GetParent", "uint", h)
if (hp=pParent) or !hp
break
h := hp
}
return h
}
OnMouseMove(wparam, lparam, msg, hwnd) {
global
if (hwnd = Selector_hwnd) and GetKeyState("LButton"){
SendMessage, 0x112,0xF012,0,,ahk_id %Selector_hwnd% ; [ WM_SYSCOMMAND, SC_MOVE ]
Selector_UpdateCtrl()
}
}
Selector_Set2Ctrl(){
local ux, uy, sx, sy, sw, sh
WinGetPos, ux, uy,,, ahk_id %User_hwnd%
ControlGetPos, sx,sy,sw,sh,, ahk_id %Selector_ctrlId%
WinMove, ahk_id %Selector_hwnd%, ,sx+ux, sy+uy, sw, sh
Gui %Selector_Gui%:Show
WinActivate, ahk_id %Selector_hwnd%
}
; Update control to match cursor's size and position
Selector_UpdateCtrl(){
local ux, uy, sx, sy, sw, sh
WinGetPos, ux, uy,,, ahk_id %User_hwnd%
WinGetPos, sx,sy,sw,sh, ahk_id %Selector_hwnd%
ControlMove,, sx-ux, sy-uy, sw, sh, ahk_id %Selector_ctrlId%
SetTimer, User_Refresh, 500
}
Selector_Size:
if (GRID) {
WinGetPos, ux, uy,,, ahk_id %User_hwnd%
MouseGetPos, mx, my
Selector_UpdateCtrlSize(mx-ux, my-uy+TITLEHEIGHT)
}
else Selector_UpdateCtrl()
return
Selector_UpdateCtrlSize(mx="", my="") {
local sw, sh, cx, cy, cw, ch
if !mx {
WinGetPos,,,sw,sh, ahk_id %Selector_hwnd%
ControlMove,,,, sw, sh, ahk_id %Selector_ctrlId%
SetTimer, User_Refresh, 500
return
}
ControlGetPos, cx,cy,,,,ahk_id %Selector_ctrlId%
tooltip %Selector_ctrlId%
cw := (mx//GRID)*GRID - cx
ch := (my//GRID)*GRID - cy + TITLEHEIGHT
ControlMove,,,,cw,ch, ahk_id %Selector_ctrlId%
}
Selector_OnDelete:
DllCall("DestroyWindow", "uint", Selector_ctrlID)
WinActivate, ahk_id %User_hwnd% ;hide the cursor besides
return
Selector_Create() {
global
Gui, %Selector_GUI%:+LastFound -Caption +Resize +ToolWindow +LabelSelector_ ;AlwaysOnTop
Gui, %Selector_GUI%:Color, FFFF
WInSet, Transparent, 100
return (Selector_hwnd := WinExist())
}
Selector_Hide() {
global
Selector_ctrlID =
WinHide, ahk_id %Selector_hwnd%
}
User_Refresh:
SetTimer, User_Refresh, off
DllCall("InvalidateRect", "uint", User_Hwnd, "uint", 0, "uint", 0)
DllCall("UpdateWindow", "uint", User_Hwnd)
return
User_Create() {
global
Gui, %User_GUI%:+LastFound +Resize +LabelUser_
gui, %User_GUI%:add, picture, +border HWNDhCursor vCursor, blank.ico
return (User_hwnd := WinExist())
}
User_Close:
gui %Toolbox_GUI%:Hide
gui %User_GUI%:Hide
Dock_ShutDown()
Selector_Hide()
return
Show( guiName, x,y,w,h) {
local GuiNum
GuiNum := %guiName%_GUI
pos = w%w% h%h%
if (x != "")
pos .= " x" x
if (y != "")
pos .= " x" x
gui %GuiNum%:Show, %pos%, %guiName%
}
SetMessageHandlers( pFlag ) {
static WM_LBUTTONDOWN := 0x201
, WM_LBUTTONUP := 0x202
, WM_MOUSEMOVE := 0x200
, WM_SYSCOMMAND := 0x112
onmessage(WM_SYSCOMMAND, "OnSysCommand")
onmessage(WM_LBUTTONDOWN, "OnMouseDown")
onmessage(WM_LBUTTONUP, "OnMouseUp")
onmessage(WM_MOUSEMOVE, "OnMouseMove")
}
DisableWindowMoving(hWnd="") {
Return DisableSystemMenuCommand(hWnd, 0xF010) ; SC_MOVE = 0xF010
}
DisableSystemMenuCommand(hWnd, SystemCommand) {
if hWnd =
hWnd := WinExist("A") ; Active window handle
hSysMenu := DllCall("GetSystemMenu", "Int", hWnd, "Int", False) ; Retrieve SystemMenu handle
return DllCall("RemoveMenu", "Int", hSysMenu, "UInt", SystemCommand, "UInt", 0) ; MF_BYCOMMAND = 0
}
#include inc\Dock.ahk
#include inc\HiEdit.ahk
#include inc\RaGrid.ahk
#include inc\HLink.ahk
HLink_Notify(p1, p2, p3){
msgbox %p1%
}
#include inc\Structs.ahk
#include inc\IE.ahk
|
The thing works almost like it shoul only for RIGHT BOTTOM movement. For Right and Bottom alone, it works, but gui size depend on where did you click to move.... thats why I need to monitor which kind of moving is done so I can disable chaniging width when you move down and chaning height when you move right.
Just drop a button and experiment. _________________

Last edited by majkinetor on Fri Jun 01, 2007 9:24 am; edited 1 time in total |
|
| Back to top |
|
 |
Rajat
Joined: 28 Mar 2004 Posts: 1718
|
Posted: Fri Jun 01, 2007 9:20 am Post subject: |
|
|
| Quote: | | This is a bit problematic for me. If anybody can do this or have idea it would be good. |
i've not been through your code, so i'm not sure if this'd do. but anyways, what i'd do is when a control is being moved/resized i'd store its current position/size and then see its new position/size and detect the exact changes. then snapping to grid is easy. _________________
 |
|
| Back to top |
|
 |
SKAN
Joined: 26 Dec 2005 Posts: 6223
|
Posted: Fri Jun 01, 2007 9:22 am Post subject: |
|
|
| majkinetor wrote: |
Oh, predators on the site, searching for its own food
(just kiddin Skan) |
No problem, but please give us the full RaGrid wrapper!  |
|
| Back to top |
|
 |
majkinetor
Joined: 24 May 2006 Posts: 3644 Location: Belgrade
|
Posted: Fri Jun 01, 2007 9:25 am Post subject: |
|
|
Ra Drug, Skan ?
I see. I will feed you with new doze regulary, don't worry.
2Rajat, 2ALL
Perhaps you should scan a code. Its pretty easy.
THe main thing to follow when reading the code - i try to follow Object Oriented metodology. ALl globals related to some entity belong to it.
For instance, Selector is object for selection. As such, it contains global Selector_ctrlId that keeps HWND of currently selected item. This will be changed in future to support more items in selection but for now its like that.
WIndow the user is creating is called User
IT also holds some data from its domain:
User_ctrlCnt - number of controls, currently used just to set variable keeping the handle (this is more for future then it is used now)
User_refresh() - function used to update the window
User_create() - creates user window, the same exists for all other windows (Selector_Create(), Toolbox_Create())
User_hwnd - holds handle of user window (Toolbox_hwnd, Selector_hwnd)
Not part of the 3 objects are currently only OnMouseDown/Move handlers and TopChild function. There are also fiew some supportive functions which are not important at all.
THe main thing about messages is to note that AHK message handlers work for all window. To distinguish which window acctually send the message (is it Toolbox, is it User....) I do this:
| Code: | OnMouseDown(wparam, lparam, msg, hwnd){
ha := DllCall("GetAncestor", "uint", hwnd, "uint", 2)+0 ;get gui handle [ GA_ROOT ]
if (ha = User_hwnd) { |
You can put bellow if branches for all GUI's that are to be monitored.
In Favmenu script I have something like this, and above is similar:
Favmenu3\msg_dispatch.ahk
| Code: | FavMenu_MessageMonitor(wparam, lparam, msg, hwnd)
{
h := DllCall("GetAncestor", "uint", hwnd)
if (h = Properties_hwnd)
return Properties_Monitor(wparam, lparam, msg)
if (h = Setup_hwnd)
return Setup_Monitor(wparam, lparam, msg)
}
;--------------------`---------------------------------------------------------------
Properties_Monitor(wparam, lparam, msg)
{
global
if (msg = WM_KEYDOWN)
return Properties_OnKeyDown(wparam, lparam)
if (msg = WM_SYSCOMMAND and wparam = SC_CLOSE)
return Properties_Close()
}
;-----------------------------------------------------------------------------------
Setup_Monitor(wparam, lparam, msg)
{
global
if (msg = WM_KEYDOWN)
return Setup_OnKeyDown(wparam, lparam)
if (msg = WM_AHKSHOW)
return Setup_Show()
if (msg = WM_SYSCOMMAND and wparam = SC_CLOSE)
return Setup_Close()
}
;-----------------------------------------------------------------------------------
|
At the start, there is serie of command
| Code: | | OnMessage( msg, "Favmenu_MessageMonitor") |
This kind of setup is more familiar for those coming from large IDE's where you can set events for each window individualy.
Note that when I have written this, there was no Gui, +Label command so I had to have even close event this way as FM3 is mergable script and it cant use commands like 2GuiClose. _________________
 |
|
| 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
|