#149 How to get owned windows and supporting controls

[Martin Lemburg]

Hi,

I want to traverse the child windows/controls of a window using twapi.

SInce some controls are more "container" controls the might own windows, but may not have child windows.

How to use twapi to get owned windows?

Another question or feature request - what's about supporting the …

• static (Static_*),
• button (Button_*),
• combo box (ComboBox_*),
• edit (Edit_*),
• list view (ListView_*),
• header control (Header_*),
• list box (ListBox_*),
• tree view (TreeView_*),
• scrollbar (ScrollBar_*),
• property sheet (PropSheet_*),
• tab control (TabCtrl_*),
• date and time picker (DateTime_*),
• animation controls (Animate_*)

… macros (encapsulating related control messages) allowing to access and to change information of those controls?

And what's about encapsulating the ImageList_* macros?

I know I already can use the messages of those controls, but the results of the send messages might need some interpretation or encapsulation, which twapi may know of, so I thought about twapi letting do this stuff.

Eventually I could help dynamically creating the control message related procedures in twapi by categorizing them related to input and output values based on existing twapi functionality, but then I need some introduction into the core/low level twapi functionality!

Best regards,

Martin

[Anonymous]

To get windows owned by a particular window, the only way I can think of is to enumerate all the windows in the desktop and call get_owner_window on each, comparing to the window of interest. Something like (in pseudo-Tcl)

proc get_owned_windows {howner} {
set owned {}
foreach hwin [find_windows blah blah blah] {
if {[get_owner_window $hwin] eq $howner} {lappend owned $hwin
}
return $owned
}

Regarding your second question, I am not sure exactly what you are looking to do (I'm not all that familiar with the user interface part of Windows). If you are looking to send specific messages to the controls and receive the results, then I'm afraid that is not something I would add to twapi. It is error prone, requires a lot of testing on every Windows platform and I don't want to land up supporting it when it breaks! Also, I do not have time to work on twapi in the foreseeable future except for bug fixes. Sorry

/Ashok

[Martin Lemburg]

Hi,

first I want to describe the script I'm working on:

I started to try to write a tcl/Tk script using twapi to help me with my eye disabilities. I need to work with a black high-contrast-mode and some applications do not respect this or are simply buggy in using hard corded colors, so that some applications show yellow text on white background or black on black.
The script I started to work on should get all controls on a window, the contained texts and rebuild the application window in Tk or redraw the window on a canvas.
The goal should be at first to be able to see, what an application want to show me in its buggy UI. The final goal is to re-assemble the UI in Tk to have the ability to interact by delegating the events from the re-assembled Tk window to the original window by sending window messages to the controls of the original window.

So I started with twapi to traverse the windows on my desktop and their child windows to see what's possible with twapi, since I didn't expect twapi to be "complete".

What I'm currently missing is the ability to send messages to windows/controls, or the support for the macros related to the previously listed controls, which provide simple functionality without the need to send messages from tcl/Tk.
Problematic may be, that some window messages or even macros need filled structures or fill structures in return. Those structures need twapi data conversion support eg to allow tcl dicts to be converted into the related structures by filling them in a "special" way.

I need such functionality to analyse the contents of listboxes or listviews, comboboxes and to rebuild trees, property sheets/pages in its using BWidget Tree and Notebook widgets.

I have not that much "private" time to develop it on my own as tcl extension, but would go this way, if you think that would be too "unstable" on all twapi supported Windows versions.
Otherwise it would be possible to categorize the macros and the additionally needed window messages to know the complicated cases in the input and return values. Based on this categorization I could use a twapi provided SendMessage to implement my twapi "extension", that could make is way into the twapi core some day.

From my experiences, I don't think, that accessing basic Windows (common) controls via messages is really problematic over the different Windows versions and I can't really try working currently onlyon Windows7 machines.
But there is sure a way to test this after a implementation.

So basically ... is there a kind of "public"SendMessage implmentation in twapi exported to tcl?

Cheers,

Martin

[Anonymous]

The SendMessageTimeout function is exported that you can call. The problem though is exactly what you describe - for messages that send/return data other than simple integers, you need to marshall and unmarshall Tcl strings into memory structures whose pointers can be passed via SendMessageTimeout. There is no direct twapi support for that. You might be able to call twapi::malloc to allocate memory (later to be freed with twapi::free), then pass the pointer to the allocated memory using SendMessageTimeout.

To set the allocated memory to the structure of interest, you can use the undocumented Twapi_WriteMemory and Twapi_ReadMemory commands. Something like

set p [twapi::malloc 100]
twapi::Twapi_WriteMemory p 1 0 100 [binary format ...whatever]

The general form is

Twapi_WriteMemory POINTER DATATYPE OFFSET BUFFERSIZE DATA

where DATATYPE 1 signifies binary data, See calls.c for details. I presume you are comfortable with C. These are undocumented functions by the way, but not likely to change given I don't have time to work on twapi. Twapi_ReadMemory is defined similarly in the same file. Grep the tcl scripts for a few examples of their use.

I hope that is enough to get you started and is what you were looking for.

/Ashok

[Martin Lemburg]

Many, many thanks for your last message explaining a way to create a tcl side interface to the C sided WIN32 messages!
I'm firm enough with C/C++ to start this the next days, exeperimenting a bit and will keep you informed about successes ... and failures!

Cheers,

Martin

[Anonymous]

Good luck! I'd be interested in how it goes and help if I can. /Ashok