Inside a MFC dialog, I have 2 overlapping rows of text boxes (what user can see is only one row). when I clicked a button, i shifted down the row at bottom, so now user can see both rows.
The problem is if I have some data loaded in DoDataExchange() for the text boxes, I wouldn't be able to see them showing when the dialog boots up. But when I click inside the text box, the data shows.
I want to know what exactly happen when I clicked a UI? What drawing functions are invoked at backgrounds? So I can fix my problem.
Thank you.
ZQ
Nothing is drawn when you click, maybe you are seeing an Invalidate() being triggered for some reason that redraws the text boxes. Or maybe the parent control (dialog, I assume) doesn't have WS_CLIPCHILDREN set, or some other funny things are happening with the WS_CLIPXXX flags (they're somewhat of a black art).
More to the point, use Spy++ to check what 'happens' when you click - i.e. the messages that are posted at each point in time.
Related
I originally had code that set the focus to the first widget in a dialog, in the onInit method. But there were problems with it: if I pressed TAB, indeed focus moved to next control (wxTextCtrl), which got the blue 'focus' color, but the 'focus' color/highlight was not removed from previous focus widget. So now it looked like both first and second control had focus at the same time...
When cycling manually (by pressing TAB) full circle (till last control and then wrap around to the first), suddenly all worked well. That is, when moving focus from first control to next one, the first visually lost focus (blue color was removed) as it should. From now on, only one item had the focus color/highlight.
So instead of setting focus on the first control, I tried a different approach: I set the focus to the last control in the dialog, which is always the OK button. Next, I want to emulate programmatically that a TAB is pressed and received by the dialog. So I wrote this (inside Dialog::onInit):
m_buttonOK->SetFocus();
wxKeyEvent key;
key.SetEventObject(this);
key.SetEventType(wxEVT_CHAR);
key.m_keyCode=WXK_TAB;
ProcessWindowEvent(key);
Now the focus indeed moves away from the OK button, but it does not wrap around to the first control.
Only when I manually press TAB after the dialog opened, the first item gets focus.
Question: why does this wrapping around to set focus on first widget not work with the code shown above?
First of all, your initial problem is almost certainly related to not calling event.Skip() in one of your event handlers, see the note in wxFocusEvent documentation.
Second, you can't send wx events to the native windows, they don't know anything about it. In this particular case you can use wxWindow::Navigate() to do what you want, but generally speaking what you're doing simple can't, and won't, work reliably.
I noticed that whole area around check box is clickable.
Is this a intentional functionality or a GUI bug? Problem is that user don't expect that if they click outside check box that value in chack box is changed.
It is intended that the user may click on the label. But clicking on the white space right of the label should actually not change the value. We will look into this.
It is different for list boxes: Because list boxes support selection as well, we decided to make only the check box clickable instead of the whole row to prevent the user from accidentally change the checked state if he just wants to select / focus a row.
I have a CRichEditCtrl with auto vertical scrolling set, which works, but not quite as I'd like. The text in the control can be updated via a message from another thread, so it can be busy updating while the user does other things, but the way it updates is different depending on whether it has focus or not (whether or not the caret is blinking). If it has focus, it auto scrolls to the most recent text (at the bottom of the window), without focus you can see the scroll bar shrinking as text is added but there is no actual scroll. Is there any way of getting it to always scroll to the bottom, so that the user always sees what's been most recently added?
I've tried sending EM_SCROLLCARET after ReplaceSel() but it made no difference. Also tried using LineScroll(), but that puts the most recent line at the top of the window, not at the bottom as happens when auto scrolling - this can also result in a blank window if there are trailing new lines ...
Looking on MSDN/forums I can't see much else to try.
Cheers for any help.
I have a semi-transparent form (using AlphaBlend) that acts as an overlay. For the user to still be able to interact with the window below I have set WS_EX_NOACTIVATE on my form so all right and left clicks go through to the other window.
However I have a few clickable labels on my form. Clicking those and performing the appropriate action works fine since despite the WS_EX_NOACTIVATE flag the OnClick methods are called, but the click will (obviousely) also propagate to the other window, which I do not want in this case.
So, does anyone know how to "stop" the click being sent through to the window below in case I already handled it in my form ? Basically I would like being able to chose whether the click "belongs to me" and does not get propagated or whether the window below mine receives it.
As Rob explained, WS_EX_NOACTIVATE is not relevant here. Most likely you used WS_EX_TRANSPARENT and that made your window transparent to mouse clicks.
To get finer grained control of mouse click transparency, handle the WM_NCHITTEST message in your top level window. Return HTTRANSPARENT for regions that you want to be "click through". Otherwise return, for example, HTCLIENT.
Wm_ex_NoActivate should be irrelevant here. That just controls whether your window receives the input focus. Indeed, if you start with a scratch program and do nothing but change the extended window style, you'll see that when you click within the bounds of that program's window, the clicks are handled in the usual way, except that the window is never activated; programs behind that window do not receive any click events.
Therefore, to make your label controls eat click events instead of forwarding them to the windows behind them, you need to find out what you did to make them start forwarding those messages and simply stop doing that, whatever that is.
Is there some sort of shortcut key that I am missing here for swapping panels around in the form editor of vs2010?
I have numerous panels which are swapped at runtime according to an enum "toggle" value and the only way I seem to be able to move them back and forth is to make one panel smaller than another and right click it. Half the time I end up selecting some other object in the action of trying to right my panels.
I figured there must be something i'm missing here.
there are icons on the layout toolbar for this task. I pick the panel in properties and move it around with those. Way easier than right clicking and hoping for the best.
edit: although sometimes the buttons are not enabled when you need them to be. Still right clicking a resize handle adorner dot will pop up the context menu where you can then choose to move back/forward.
I still wish there was some key combo I could press. Hitting the 4px of display area that the adorner dot occupies on my screen is sort of a dexterity test of sorts and slows me down.