Drugwash wrote:
I actually did that regedit thing!
But I would've thought, in such a powerful OS, partial results would pop up on an incremental search. Nah, the stupid thing wouldn't show anything in the results window until I typed the very last letter of the word 'regedit'. What's that Indexer service for, then?
Incremental search works fine in W7. And I've completely disabled the Windows Search and Indexer services. But the search continues to work fine, although a little bit slower.
Drugwash wrote:
There's a lot to talk on the GUI subject. BTW, the word 'widget' has a not-so-pleasant conotation to me ever since WxWidgets started failing on 9x, long ago. In AHK they're called 'controls' anyway and it may be better if you called them that way, for all readers' understanding.
Noted.
They are called "Gadgets" in the Amiga terminology, and "Windows" (yes, Window!) in Tcl/Tk. I've used Widget because it's a unique name. But I agree that Control is better when we are speaking of AHK.
Drugwash wrote:
Controls may be positioned relative to each-other using x+/-<value> yp+/-<value> and so on. This might work acceptably for vertical alignment, but horizontal alignment could be more difficult to achieve. Sections may help, but they must be chosen carefully. If I may say so, your usage of the Section parameter in the topic's script looks kinda overkill.
I use Section often, and even when it's not really necessary, because I think it is good to start a new section each time a new column or line begins. It's an attempt to clone my method of building GUIs with Tcl/Tk.
I agree that I don't master correctly the placement options, but the doc on that subject is confusing.
It is possible to place a control relatively to the previous control, that's right, but only relatively to the upper left corner of the control. AFAIK, there is no simple way to place them below or to the right side without having to compute the height or width of the widget, and that's currently impossible. For example, I use XS without YS to place the control below the previous Section. But I haven't found a good way to place it below AND leave a bigger spacing. Maybe I'm totally noob on that matter, but anyway, the AHK method is obscure and confusing.
With Tcl/Tk, I have never typed a X, Y, W or H argument. I have to type a specific number of pixels only when I want to insert a spacing between two controls. The rest is totally automatic (although the possibility to place the controls at fixed position exist, but is not recommended).
Drugwash wrote:
Dunno what to say about automatic controls resizing - is that possible for all registered controls?
Well, of course, a simple label, for example, cannot be resized (without changing the font). But it can be placed in a zone that can be expanded when the window is enlarged. You can, for example, create an invisible frame (with options to fill the available space in the X and/or Y directions), and place the label in the centre of the frame. When the window is enlarged, the frame is automatically resized as well, and the label stays attached to its centre.
This is a simple example in Tcl/Tk:
Code:
toplevel .win ;# creates a new window
wm title .win "Simple example" ;# give it a title
frame .win.f ;# Create an invisible frame in the window
pack .win.f -padx 4 -pady 4 -fill both -expand 1 ;# Pack the frame in the window (leave a 4 pixel border, and tell the frame that it must expand vertically and horizontally)
label .win.f.lab -text "Keep cool:" ;# create a label in the frame
pack .win.f.lab -anchor e ;# and attach it to the "East" border of the frame (to the right side)
checkbutton .win.f.cb -text "I am cool!" -variable ::vars::cool ;# create a checkbutton controlled by the variable 'cool'
pack .win.f.cb -fill x -anchor w ;# attach it to the West side of the frame
frame .win.f.f -height 10 ;# add an empty space of 10 pixels between the checkbox and the OK button
pack .win.f.f -fill y -expand 1 ;# And tell it to expand vertically
button .win.f.b -text "OK" -command {CloseWindow .win} ;# Create the OK button that calls the function CloseWindow (with the parameter .win)
pack .win.f.b -fill x -expand 1 -anchor s ;# the button must occupy the whole width of the frame and be attached to the bottom of the frame
update ;# Force Tcl/Tk to compute the size of the window according to its current content
wm minsize .win [winfo reqwidth .win] [winfo reqheight .win] ;# and use that size as the minimal size of the window
set ::vars::cool 1 ;# the checkbox is now ticked.
A Control is identified by its path. So, for example, .win.f.b refers to the button "b" in frame "f" in the window "win". That hierarchical method of organizing the controls in groups and attach them to invisible frames is very powerful. For example, without the fill and expand arguments, the frame will adapt itself to its content. And of course, when the window is created, it is also automatically sized according to its content (the frame).
In this example, if the window is enlarged, the frame will "follow" it (due to the -fill both and -expand 1 options), the label will always stick to the left size (-anchor e), and the button will always occupy the full width (with the "OK" text in the middle of the button).
The .win.f.f empty frame is used to add a 10 pixel blank zone before the OK button. Due to the -fill y and -expand 1 options, that empty space will automatically be enlarged if the user enlarge the window vertically, and the OK button will always be near the bottom of the window (due to the South anchor):
Of course, you can create other frames as well, inside or beside or below the first frame:
Code:
frame .win.f2 ;# Create another frame
pack .win.f2 -padx 4 -pady 4 -side left ;# And place it to the left of the first frame
# ... ;# create other controls in the left frame
This is a demo of the "pack" method. You can also use the "grid" method, especially useful if you need to align many controls in a grid, but still want to be able to resize the window, and automatically enlarge some columns or rows of the grid. There is also a "place" method, similar to the AHK method, but it should NEVER be used, except if you really need to place controls at fixed positions (for example on a map). You can use any method in any frame. So, it is perfectly possible to use the 3 methods in different zones of the same window.
(In my example, I've used the default Tk controls, that have the same look under all versions of Windows, Linux and Mac, but you can also use themed controls.)
I haven't defined the CloseWindow function, but note that you don't need callback functions or labels (except if you really want to control yourself some aspects of the GUI): everything is automatic.
The CloseWindow function could simply contain something like this:
Code:
proc CloseWindow {win} {
if {$::vars::cool == 1} {
tk_messageBox -type okcancel -default ok -title "Test" -icon info -parent $win -message "You are cool!\nFine."
}
wm destroy $win
}
Note also the good syntax of the tk_messageBox instruction. No need to refer to the doc to understand it!
Drugwash wrote:
Not to forget that, ultimately, AHK is not a compiled language, therefore cannot achieve the same results at least in terms of speed, as compared to ASM, C/C++ and whatever else is out there. But for a quick and dirty home-made trick, it's more than enough and this used to be it's main strength: simplicity in creating simple tasks.
I fully agree. It's why I like AHK. It has powerful enough commands to easily build simple GUIs, and especially tray menus (but it makes me sick when I need to create somewhat complex GUIs). Also, I use it mainly for what it is made for: automating tasks with third party programs. That's totally impossible to do with Tcl/Tk. The speed is usually not very important for that kind of tasks.
Login
Register
FAQ
Search
Stolen from SKAN
