WinAPI can get text from particular windows. However, VSFlexGrids are resistant to this since their grid data don't seem contained in easily-accessible child windows.
I've used Spy++ to analyze the VSFlexGrid in question, and it has no children. Yet, when I click a particular grid cell, a new child window seems to be dynamically created.
Question: Given this behavior, is there an easy way to get grid data from a VSFlexGrid using the Windows API, or some other "efficient" method? I'd like not to have to scrape screenshots or click each grid cell individually, as those methods would be slower than a WinAPI call (if a WinAPI method actually exists).
Related
So before I continue developing my accessible table I read this, on exposing data tables and the general MSAA documentation and I want to clear up a few things before I actually go ahead and write out this implementation, just so I can get everything just right.
For the record, this table is strictly owner-data and is row-based, where a given row can be selected, and a single cell within this row can be focused. Otherwise it behaves similarly to a listview control, but is not one, so I'm not going to try to take advantage of its accessibility features. In particular, any column can contain text, images, or checkboxes (and I might add more features); there might be background colors and text editability in the future as well. All cells in a given column have one of these types. The type will not change during runtime.
I am choosing to use MSAA because I still need Windows XP support, and I would rather not require developers and end users to have both SP3 and the .net framework together, which UI Automation seems to require (and even if the SP3 part is wrong, the "is not standalone/does not come out of the box with the OS" part still makes me uneasy about implementing that).
Is it process-safe/thread-safe to call my internal control functions within the accessible object method implementations, or should I use WM_USER messages to make sure everything happens all on one thread of one process? (In addition, would my error handling/debugging traps be run in the client or in the server in either case?)
From what I can gather, I need to build a three-level IAccessible hierarchy: the table itself on top, followed by each row, followed by each cell in the row. However, the various IAccessible methods that take a child object only take a VT_I4 VARIANT to specify the child. Does this mean I'm going to have to create an IAccessible for each row as well, or for each cell as well, or something else? Should I have a standard accessible object for each of these? Can they share? And what about NotifyWinEvent(); how would I indicate that a given cell has changed? Or should I say the whole row has changed...?
If the answer to question 2 is "yes", I'm going to wind up with a lot of IAccessible objects that need to be notified when the table control is destroyed. If the answer to question 1 is "it is not thread-safe", then is it safe to hold a lock in my IAccessible methods whenever I access my table control and have that hold the lock when it's time to invalidate all those IAccessibles? Or should I investigate some other approach? I see talk on MSDN of "proxy objects" but I'm not really following how that would help... especially if I need to make lots of IAccessibles.
From what I can gather I need to return (number of rows) + 1 rows in my table's get_accChildCount() method, with the first row being full of column header cells. But I'm not using a custom header control; I'm using the standard comctl32.dll header control. Should I hide that control and construct my column headers according to the Exposing Data Tables document or should I relegate the first row to the header control? I don't see a way to do both... (I do not have row headers, so will not be implementing that.) Columns can be user-resized, but may be automatically sized to fit until the user first does so (maybe).
Is it safe to relegate IDispatch methods to the window handle's standard accessible object? Even in the case of the row and cell IAccessibles? Or will the standard accessible object's IDispatch not call my IAccessible methods?
What should accDoDefaultAction() do for a checkbox cell, toggle the checkbox state? And for an editable text cell, should it enter editing mode?
Thanks. (Hoping none of this sounds dumb...)
UPDATE 6 January 2015
I changed the wording of some of the paragraphs above and have one more question:
How do I correctly check for errors from LresultFromObject(), by casting to an HRESULT and checking that, or by comparing a signed version of the LRESULT value and seeing if it's less than zero, or something else?
I have a windows application which has several sub-forms. i have to navigate through 5 or 6 forms to reach the form i need. this is time consuming since i have to open it several times through the day and i do it daily.
my need: i dont have the source project for this application, i got it as an executable program, but i need to create some application that does these steps for me automatically. In other words i need to find a way to automatically click the buttons that navigate through the forms and opens the form i need from step one.
is there any way i can do this ?
There is indeed, though generic solutions already exist to perform just this kind of function to arbitrary programs.
You can use Spy++ or a resource-editor, like ResHack or ResEdit to look at the program and get the control ids of the navigation buttons.
Once done, you can get a handle to the program itself and then send messages to it's WindowProcedure that would be generated if the user clicked the controls with a mouse,
Another alternative, is to get the position of the running target application, after you've got it's HWND, by using the GetWindowRect function. You could then use this position along with vert/horiz distances to generate mouse events.
The two have more-or-less the same result, though some applications won't work with approach #1.
In one instance, you need to use Spy++ to get the control IDs.
In the other instance, you need to use an image editor to get the pixel offsets of the controls.
In both instances, you'll need to use FindWindow, along with the window's title-text in order to get a HWND handle.
You could use a combination of the two - asking the program itself with GetDlgItem for the handle of the controls you need to click. You could then query the control for its position, before using mouse_event to position the mouse above it and again to click it.
Quite a few ways to skin this cat, actually.
Pre-existing solutions like AutoIt are said to be very easy to use and will be much easier than coding a new program for each target.
I need to implement a threaded view of sorts in an old VB6 app. It should look similar to this:
So, it's like a TreeView of sorts but there are buttons on the right (for each row) that could be pressed. The view does not need to collapse - it always stays in the expanded mode. The users should be able to respond to each node (via the comment button on the far right). And, of course, users should be able to scroll through the entries.
What are some of the ways I could implement this? I am open to 3rd party controls, paid or not.
VSFlexGrid has an outline mode. You can set the indent per row via the RowOutlineLevel property. It supports word wrap, images, etc within its cells/columns so you should be able to get pretty close to what you want. It also supports owner-drawn which lets you fully customize the cell painting (for example, to get those rounded corners).
I'm sure there are other controls out there as well...
In my WinAPI program I use PropertySheet for a settings dialog box. I use property sheet with pages (tabs), i.e. I use PSH_PROPSHEETPAGE flag. But the software now have too many parameters for such a type of property sheet. So I want to use PropertySheet with treeview: the treeview on the left and the page with paramerets for the currently selected item in the treeview - on the right.
How can I do this? Can my current property sheet be modified for this and how?
(using only WinAPI, no MFC)
Standard property sheet is no longer good enough for you, so you basically have two choices here. You can either design a window (modal or modeless, dialog based or not) to host all your controls in a single view, with tree view, possibly tab control as well, and showing/hiding elements to follow tree view selection. And you will move all your controls into this window.
Or instead, you can create a similar window which hosts property pages. On tree selection change you will switch property pages as if they are selected by tabs in standard property sheet. The point is that you can use your existing pages intact making this new settings windows imitating behavior of standard property sheet. This is perhaps a more complicated thing to do, but should be flexible enough to do once and accept various pages, and you don't also need to touch your existing pages code leaving it good for both standard and this custom sheet with a tree.
Both ways assume you need to do quite some work since you are giving up using a standard piece of code - the property sheet window.
I have a hierarchical flexgrid control with the ToolTipText property set, and when I run from source the tooltip displays as it should. But when I compile it and run that way, the tooltip doesn't display.
I've tried to remove anything listening to MouseMove in the hopes that that would fix it, and when I add some code to put the tooltip text into a message box, it appears to be set correctly. Can anyone think of why this would be happening?
Update: It appears that the problem arises when I host the grid inside another user control. E.g.: make container.ctl, which is just a blank control but with ControlContainer = True. Then make gridholder.ctl, which is a mshfg inside of a container.ctl. Lastly, embed gridholder.ctl into some form. Tooltips on the flexgrid don't appear to show up.
I'm interested to see how reproducible this is...
I haven't found a workaround for this issue yet, but I have a better idea of why it's happening after some testing and stepping through some of the VB6 runtime code in WinDBG.
The first interesting thing is that VB6 doesn't use the standard tooltip display mechanisms provided by Windows. For example, it doesn't use WM_NOTIFY messages to show/hide tooltips, or any of the other "standard" tooltip support described in the documentation explaining how tooltips work in Windows.
Instead, the VB6 runtime has its own way of managing and displaying tooltips. In principle, it's similar to in some ways to the standard Windows way of dealing with tooltips, but it's also different in a quite a few areas.
A breakdown of how VB6 does tooltips:
When a VB6 program starts, the runtime uses SetWindowsHookEx to install a mouse hook for the program's main thread.
The mouse hook intercepts all mouse messages sent to the program, in particular all WM_MOUSEMOUSE messages
Whenever the mouse hook runs, it calls an internal method in the VB6 runtime to get the object pointer (HCTL) of the control that the mouse is currently over top of. Note that this is an actual COM interface pointer, not a window handle.
It translates the HCTL to the corresponding window handle (HWND).
It checks to see if the mouse position is within that window's rectangle.
If so, it retrieves the ToolTipText property for the control. If this is not empty, it creates a tooltip window and displays the tooltip after a 700ms delay.
The problem with the MSHFlexGrid (and I imagine other controls that are not standard VB6 controls) is that this code doesn't retrieve the correct HCTL when you hover over the control and it's inside a custom container.
In that case, the code retrieves the HCTL of the custom container, not the HCTL of the MSHFlexGrid itself. Therefore, it retrieves the container's ToolTipText property (which is empty) and not the grid's ToolTipText, and therefore won't display a tooltip.
I'm not sure exactly why it does this, because as noted in the comments on your question, all of this works correctly if you use a PictureBox as your container.
I suspect the PictureBox has code to handle this correctly that is not included when you create your own container.
I'll update this answer with an actual workaround if I can find one. The only thing I can think right now is to somehow "sync" your container's ToolTipText property with the grid's ToolTipText property, so that when VB6 requests the container's ToolTipText, it will return the value of the grid's ToolTextTip property instead.
This is easier said than done, however, because ToolTipText is an extender property, and extender properties take precedence over properties that you write yourself that have the same name.
After a bit of research, I found what I think is the underlying problem. Your user control is not implementing any method for the controls to interact with. User Controls that are Container Controls need to implement the Extender functionality. These two links are the best I've found on the subject so far.
http://www.justvb.net/obook/ch7.htm#UsingtheExtenderObject
http://msdn.microsoft.com/en-us/library/aa733622(v=vs.60).aspx