CPropertySheet: How to get the child page from OnDrawItem - winapi

I've added some code as found here Big problems with MFC/WinAPI to colour tab titles the same as the reset of the dialog, which works, but unfortunately all the tabs end up with the same name. This doesn't surprise me all that much as GetCurSel() is used to grab the text to use, and only one tab can currently be selected, but I'm struggling to see how you access the correct tab index from OnDrawItem().
I've googled and had a look on MSDN but don't see how anything passed to OnDrawItem lets you know which tab is currently being drawn, rather all the examples I've seen assume you're only interested in the one currently selected. All I want to do is something along the lines of GetWindowText() on the child window and redraw with that. I'm also unsure of the parent/child/sibling relationship between the sheet, tab control and page - it depends who you listen to.
I should probably add that I'm also unsure why all the tabs are redrawn when I select one. I don't know if this is normal or something specific to this implementation (that's something I'm looking at, but like seemingly everything else in this code base it's multiply inherited several times over ...).
Cheers for any help.

Not to worry, I now realise lpDrawItemStruct->itemID holds the tab index so I can get a handle to the tab using that.

Related

is it possible to scroll to specific position in browsing?

I am no programmar nor tech savvy person myself.
I just wanna know if it's possible to achieve this goal:
The default behavior of the browser(e.g. chrome) is it sends one page up or page down depending on where I click(above or below scroll thumb).
But when clicking somewhere on the scroll track, I wish it navigates right through the target position in the web page.
for better understanding, here's the screenshot of cnn.com main page for reference:
(In first screnshot, I highlighted where I will click.
Second screenshot is the default behavior of the browser as a result.
Third screenshot is what I want realize for my own convenience. it's useful when navigating through long articles.)
I think it is almost impossible to do this on my part because maybe it's hardcoded in browser's engine level or something, but I wanted to make sure it really is.
or any workaround like making autohotkey script or something?
thank you so much!
There seems to exist a trick with Shift, but it doesn't work in browsers.
However, you are manipulating a browser, and browsers have a built-in scripting language — JavaScript. Here's the setup you need to do:
Go to the place on the page you want to scroll to.
Open the developer console (Ctrl+Shift+I and then click on the "Console" tab). This shouldn't interfere with the scroll position.
Type window.scrollY and press Enter.
After that, the console will output the amount of vertical scrolling. In the following AutoHotkey code I'll use 12345 as an example; replace it with the value you have. Note that it also scrolls to the left margin.
Send {F6}javascript:window.scrollTo(0,12345)`%3Bvoid`%200{Enter}
It appears that, due to a bug, this doesn't work in Firefox.
I know your problem, I think chrome must have this config, you can type in the address bar "chrome://chrome-urls" for searching

macOS: Selecting items from a list by typing on the keyboard

The NSTableView has a feature, called Type Selection, by which the user can type the first letters of a listed item and the view automatically selects the first hit and scrolls to it.
I like to have a similar functionality in a NSCollectionView, where I list images by name.
Before I start writing such code by myself, I wonder if there is an API that can help me with this.
I am especially worred about getting the timing right, as I want to have it use the same timing as the NSTableView does. I imagine that it even changes depending on the user's System Preferences for typing. Also, the NSTableView will select other items with the same typed prefix if waiting long enough. All this can get quite complicated if I want to get it right. I don't want to miss anything.

Dynamically load SubVI frontpanels

I want to display multiple SubVIs (each one has a set frontpanel with controls and indicators) in my main VI. The problem is: usually only 2 or 3 are active at the same time, the rest are deactivated.
Let's say I got an array of VI references for the active SubVIs. Is it possible to display the SubVIs in a table, where each SubVI gets its own row?
I'm basically looking for a container similar to a Tab Control, but instead of tabs I want to display the VIs row-wise.
Thanks in advance.
The best choice for you is sub panels. http://digital.ni.com/public.nsf/allkb/D587067E18E0E70186256D44007B91FE
Example:
https://decibel.ni.com/content/docs/DOC-18164
Also there is nice way with xcontrols, but it is complicated and takes more time to implement. Anyway below is link about xcontrols:
http://www.ni.com/tutorial/3198/en/
I was unable to place a Sub Panel (which shows a VI's front panel) in an array control, but I was able to place it and its VI reference in a cluster, and then place that in an array:
After that, you could set the VI Ref's visibility to hidden, and tweak the array's chrome. Going further, I don't know if LabVIEW provides a way to give that subpanel a VI reference when it's in a container, so your mileage may vary.

Preferred UX for an empty-but-selectable item in a menu

In a project I'm working on, we have a nav menu where items are colored when the relevant section has information beneath it, or faded when there's nothing available to the user. In the case of an admin, these items may have no useful information but may still be clickable (since things like "Add news item" or "Add file" are implemented as sub-menus).
The call from On High has come down to make these admin items stand apart somehow. Since we're already using the faded text for unclickable items, I was wondering if there's an established UI convention for denoting that an item is clickable, yet contains no information.
And yes, I've already asked why we're bothering to show items that aren't available to the user. The short of it: because On High wants to.
Short answer, no I don't think there's a convention for this. Lots of people would say if its not applicable, don't show it. However, there's some debate on this. One of the reasons Microsoft started using The Ribbon in MS Office is because they wanted to get away from dynamic menus where options hid and showed 'intelligently'. Users couldn't figure out the rules for what appered where, and when.
Maybe separate the concerns here: 1) how to indicate the item is clickable, and then 2) how to indicate the item contains no information.
The first one is relatively well established -- blue underlined text. You can also make it look like a button Of course, if you've got a site-specific look for your hyperlinks, use that. Basically don't break the users' expectiations of what things are clickable.
Second, how to show there's nothing there worth clicking on. I think what you want is some visual indication of the priority/utility of these admin links relatively to others. Some options:
Can you move the admin links to the bottom of a list?
Add a number indication how many things are on the other side of the link?
Strikethrough on the text?
Since there are no hard-and-fast conventions on this sort of thing, just remember that anything you do which is consistent will work. Some things will just work better than others.
No matter what you choose, the user will learn after a few tries what the new method of empty indication is.
If it is well thought out and consistent, they will probably get it after a couple of clicks.
Also, remember that too many highlights, colors, fades, and underlines will wash out any amount of effectiveness at visually organizing your menu so it is easy to use. At some point it can actually get harder to use by over-organizing things.
Think about it this way: There are two boxes sitting on a virtual shelf. One is red and the other is blue. The selected box is identified by a differing color than the other box... Now, which is the selected box?

How to implement (UI-wise) a button

I am designing the (G)UI of a program, and have stumbled across a problem; The program will convert a number into different units, and the layout of a unit been converted to is:
[Unit name (when clicked gives information)]
[Special status, if any]
[Output in textfield that can also be used for input (to convert to other units)]
I want the user to be able to copy an outputnumber onto the clipboard, without having to mess around with highlighting and finding the right buttons to press. So, I thought I'd make a button after the text-output field, saying something like "C" or "Copy".
But I was reading on joelonsoftware.com yesterday, and discovered that users seem to be cursorclumsy. So what should I do?
I've thought about a number of different options:
Click on textfield to copy to clipboard - BUT: I want to use it for input as well
Pressing a numeral on the keyboard to copy the respective one - BUT: There will probably be more than 10, and I need them for new input
Bigger Copy button, like on that actually says "Copy" - Hmm, would this work? I know that I like to use the keyboard when I can, so a solution involving it would be nice.
Each unit will have its own space, where everything (name, textfield etc.) fits in. What if it would copy to clipboard when clicked anywhere in that space except for on the name or textfield. - BUT: What if you miss, meaning to click below one textfield, and clicking above another?
But what about highlighting the unit's space as I went along? - Could still mean trouble...
What do you think? I think I just might opt for #3 - Bigger copy-button..
There's nothing wrong with a Copy button after every field if you feel that it's going to be a very common operation.
Two suggestions, however:
In terms of look and feel, make sure that the button is clearly associated with the field. For a text field, the best way to do this is to put the Copy button inside the text field (on the right side - but be prepared to handle RTL languages by switching its position as needed!).
To avoid making it overly big, don't use any text, but rather use the stock Windows icon for Copy (like this one: ), and put the text into its tooltip. If you do that, you may also get rid of button border entirely, further reducing its size, though you'd still want some visual hover indicator to make it clear that it's an active UI element. In fact, you might want to specifically copy Vista/Win7 Explorer (also seen in IE7/8) UI for location field and the Reload icon in it.
I think the solution #3 is the best in your list, but I would like to see a sketch of your GUI.
What ever you do, it is important to use the OS standard keyboard and mouse event bindings and preferable look-and-feel too otherwise users get confused.
For sheer speed, the keyboard is the way to go. How about letters A-Z to copy the text boxes instead? Skip “E” to allow scientific notation to be inputted. Potential speed is high, but learnability is low. I’d expect users will have a hard time figuring out this UI even with explanatory text on the page/window, and if users have to read explanatory text, then the time that takes will likely negate the time savings of the UI, unless the user is using the app all the time (Joel also writes correctly that users hate to read).
For an app that will be used only occasionally, the big button is a better choice, the bigger the better, as predicted by Fitts’s Law. And absolutely label it “Copy,” not “C” and not an icon, to maximize learnability. Your other ideas have learnability and tolerance issues without the speed of the keyboard.
That said, I think you’re taking what Joel says too far. Certainly you want to eliminate unnecessary clicks, but the typical design for this type of app would require one click on the text box (which should by default highlight the whole value) followed by one click on a Copy menu item –or better, Alt-C or Ctrl-C from the keyboard. It’s hard for me to imagine a task where saving one click or a couple keyboard presses would be worth the clutter of a bank of Copy buttons beside your text boxes. Are you also going to have buttons for Paste and Clear? At some point the clutter will slow your users down more than the extra click.
How often are users going to be copying? If it’s really dozens of times per session, then you should re-think the whole design approach because any copying and pasting of one number at a time is going to get tedious. Maybe you should support batch processing, taking multiple numbers at once and outputting results in a form already suitable for the expected use. Maybe have it work within other apps like the way Enso does: user highlights a number in any document or text field of any app, commands Convert - Feet - Meters and it’s changed in the document or field.
If you accidentally click on the wrong area, you could just click on the right area after that. If your issue lies in the user not knowing when they click on the wrong area, just highlight the last-clicked area.
Is there a problem with copying whatever is in the textfield when they click on it? So what if it's being used for input? They're just going to copy the value they need after they type values in.
You could also have a ctrl-click or shift-click in the text box be a copy.
Most people know how to copy text on their own computer. Perhaps the best solution is to just auto-highlight all the text in a textbox when it gets focus so they can just ctrl-c to copy or start typing to begin input.

Resources