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?
Related
I am trying to port to Python 3.x a small gui application that I have written in Matlab.
The app contains a Matlab uitable, with which you can program bitfields of registers of a microcontroller. Actually you can create a panel which groups some register-bitfields that are important to you for debugging at a specific point in time (kind-of a watch window in a compiler IDE).
It looks like this:
Gui Table used to write to register bitfields of a microcontroller
So, each row of the table can be used to program a specific register bitfield.
There are 4 columns:
1. Register name (drop down list)
2. Bitfield name (drop down list)
3. Value to write (string)
4. Format (Hex or Dec drop down list, irrelevant here)
In order to use this application, one first clicks on the register name drop down list, where all registers are shown (detail: using a text box one can apply filters to narrow down the list size).
When the register is selected, the drop down list of the bitfield column updates automatically so that it contains only the bitfields of the chosen register. This happens with the help of a callback function.
Then, the user has to enter a value and a format, and only if all cells contain valid content, then a register write command is issued (via some debugger interface).
This worked OKish; sometimes the bitfields list was actually the one of the previous register added in the table, but this could be detected and have the entry cleared so that the user can try again. Also when the number of rows becomes very high and scroll bars appear, then if the user tries to enter a register at the bottom, every time they click on the drop down list, they can choose an entry and then the scroll bar position will automatically change showing the beginning of the table. This makes the process of entering registers quite cumbersome. As far as I know, the uitable of Matlab did not have accessible properties to control this behavior.
Since I am a hw engineer with limited sw technologies knowledge, I am wondering if there is a natural way to support this in Python 3.x, say with some structured (e.g. xml) data container that can naturally map to a gui component, without so much callback programming and data validation. The ideal behavior would be that the user starts to type directly at the register name drop down list (not possible in Matlab), and dynamically gets a filtered version of the register names list.
I am completely new to python, just installed Anaconda. I have found some interesting classes in PyQt:
QListView Class,
QListWidget Class,
QTableView Class,
QTableWidget Class.
However, I would like to have the combined functionality of the tableview with a listview, as is the case with the uitable in Matlab. Or even better, a text edit input that turns into a drop down list after typing a few letters.
The pyqtgraph.tablewidget seems to augment the functionality of QTableWidget, but I think this is still not what I need.
So, if the above is not possible, or would involve heavy programming, maybe all I need is to change approach and have a single separate search box with autocompletion, which looks into a "flattened" version of the registers database, and returns results in the form my_register_1.my_bitfield_1 (maybe allowing the user to search simultaneously at both register and bitfield names). When the user clicks on one item of the "autocompletion list", then the selected entry is mapped to the currently selected line in the tableview, adding both the register name and bitfield in read-only table cells. The "value to write" cell should still be editable, and when it gets valid data it should trigger register write command...
I would appreciate if you could guide me where to look. Thanks!
You should use the Qt model/view architecture. This allows you to have a representation of your data (the "model"), which is separate from how that data is represented (the "view"). So you set up a table of data, and then set up a view to represent that data. When you switch between different data sets, you tell the view to display the new data set. The tutorial I linked to explains this in some detail
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...
This is easy in .NET (not my question) but I'm trying to figure out if it is possible to simply change the text of a string in a Win32 list box control given an index.
There is a GetText function that takes an item index but nothing to change the text of an existing item/string. My workaround will be to remove it and add it back in the box (which is also a weird prospect since there is no single command to add a string + item data -- these must be done carefully by inserting the string and then setting the item data on the index of the inserted string, which is tricky (not possible?) with sorting active).
Yes, the lack of a LB_SETITEMTEXT message is a bit weird.
You should put your Delete+Insert+SetData calls between calls to WM_SETREDRAW...
At the risk of being off topic...
I tend to use the ListView control all of the time. You'll want it in report view to mimic a listbox, and, as a plus, it supports multiple columns.
Oh.. and it has a LVM_SETITEM Message :)
http://msdn.microsoft.com/en-us/library/bb761186(v=VS.85).aspx
Although this question is old, but I think this documentation presented by Microsoft will be able to answer anyone questions based on this one.
So according to Microsoft documentation which you can find here
Changes the text of a list-view item or subitem. You can use this
macro or send the LVM_SETITEMTEXT message explicitly.
void ListView_SetItemText(
hwndLV,
i,
iSubItem_,
pszText_
);
And it also presents other macros for managing the list box. You can build a wrapper around this macros to simplify handling list view controls, etc.
I'm new to developing on the Mac and am looking to implement an interface similar to Spotlight's - the main part which seems to be an expanding table/grid view.
I was wondering if there is a component Apple provides for creating something like this or is available open source else where.
Of course if not I'll just try and work something out myself but it's always worth checking!
Thanks for your help in advance.
New Answer (December, 2015)
These days I'd go with a vertical stack view ( NSStackView ).
You can use its hiding priorities to guarantee the number of results you show will fit (it'll hide those it can't). Note, it doesn't reuse views like a table view reuses cell views, so it's only appropriate for a limited number of "results" in your case, especially since it doesn't make sense to add a bunch of subviews that'll never appear. I'd go so far as to say outright you shouldn't use it for lists of things you intend to scroll (in this case, go with a table view).
The priority setting can be used to make sure your assumption of what should be "enough" results doesn't cause ugly layout issues by letting the stack view "sacrifice" the last few.
You can even emulate Spotlight's "Spotlight Preferences" entry (or a "show all" option) by adding it last and setting its priority to required (1000) so it always stays put even if result entries above it are hidden due to lack of space.
Lately all my UI designs for 10.11 (and beyond) have been making heavy use of them. I keep finding new ways to simplify my layouts with them. Given how lightweight they are, they should be your go-to solution first unless you need something more complex (Apple engineers stated in WWDC videos they're intended to be used in this way).
Old 2011 Answer
This is private Apple API. I don't know of any open-source initiatives that mimic it off-hand.
Were I trying to do it, I might use an NSTableView with no enclosing scroll view, no headers, two columns, right-justified lighter-colored text in the left column, the easily-googled image/text cell in the right column, with vertical grid lines turned on. The container view would observe the table view for frame changes and resize/reposition accordingly.
Adding: It might be a good idea also to see if the right/left justified text (or even the position of the columns) is different in languages with different sweep paths. Example: Arabic and Hebrew are read right-to-left. Better to adapt than to say "who cares" (he says flippantly while knowing full well his own apps have problems with this sort of thing :-)). You can test this by making sure such languages are installed on your computer, then switching between them and testing out Spotlight. Changing languages shouldn't pose an issue since the language switching UI doesn't rely on reading a foreign language. :-)
What would be the appropriate way for selecting a particular row in a paginated view.
For example, while trying to select a particular row in Yahoo Inbox you can use the pointer to select the check box and if you try to click beyond the check box, no action is taken.
But while trying to select a particular row in GMail Inbox you can use the pointer to select it or if you navigate away from the checkbox it changes into a thumbnail but allows you to select the row.
Which method is preferable from a usability perspective and how to implement the thumbnail based selection as done by GMail
Both methods are appropriate, and both can be very usable.
I think the main difference is that row selection (the system used by Gmail) is more like a desktop application and a little less web-like. With links (like in the Yahoo inbox or StackOverflow), it's completely obvious that you're supposed to click on them. With rows, you sort of have to figure that out that you can click them, but I doubt it takes people long.
One thing to keep in mind is that, if you go with row selection, it's probably a good idea to bunch together any other clickable control (like checkboxes, links, or "favorite" stars). This way, you can click anywhere on the row. If you intersperse controls along the row, you increase the likelihood users will make clicking errors (aiming for the row but accidentally clicking some other control), and it will make it harder for users to recognize that the row itself is a clickable region.
So, both are perfectly acceptable user interfaces. You'll have to decide which one is a better match for your particular situation. I think, in general, links are a little bit more versatile, but with clickable rows, you know you can click anywhere and it will work.