By default RadTreeNode becomes editable after (http://www.telerik.com/help/aspnet-ajax/p_telerik_web_ui_radtreeview_allownodeediting.html)
"End-users can edit the text of tree-nodes by pressing F2 when the node is selected or by clicking on a node that is already selected (slow double click)."
This is unconvenient, that whatever was clicked twice start being edited, even if clicks are spearated by far.
How I can change its behaviour so edit happens on normal, fast double-click?
Turns out, you just have to rely on context menu approach, and start editing item from context menu handler. AllowNodeEditing="False" can be set, yet OnNodeEdit="HandleNodeEdit" and the like will still work, when editing is triggered manually using appropritate client API function from context menu handler function.
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 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.
My test needs to click a link from a rad tools menu that it can only find some of the time. Even when it finds the link ByText it cannot double click it. If I hover the menu item it will always find it. Cannot find a hover in Watin, otherwise I've tried refresh, sleeps, focus, keypress, WaitUntilExists, double clicks, etc. Its using a class rmText from rad tools.
The only thing I've found to work is hovering that drop down while the tests are running...
Wish I could just do that for a few seconds...
//process would be a menu item below the radtool menu item that only shows up when certain conditions exist (but always does with the hover)
if (ie.Link(Find.ByText("process")).Exists) //sometimes I get through here
ie.Link(Find.ByText("process")).Click(); // this works only if I hover
Might be that creating the menu item is taking some time. Calling Exists does check if it exists now, maybe if you wait a few (milli)seconds it will be there. Try calling
ie.Link(Find.ByText("process")).WaitUntilExists()
This will time out if the element never appears, otherwise you can savely call the click.
BTW maybe you can get rid of the exists check, WatiN does call WaitUntilExists by itself too before calling Click().
HTH,
Jeroen
I have CMenu instance on which I add multiple items. For one of the items I added in it, I set the MF_HILITE flag.
When I show the menu, the appropriate item get hi-lighted correctly, as requested. The problem is that it stays hi-lighted until I move the mouse over it and leave. I only want one item to be hi-lighted at the time. It seems that Windows does not un-light it when another item is hi-lighed.
How could I force it to be un-lighted as soon as another item get the hi-light? I could not find any mouse-over callback or message for the menu, and I could not find a invalidate either.
You're using MF_HILITE in a weird way. The item isn't actually highlighted, it's just drawn like it is. If the user presss enter, the "highlighted" item won't be selected.
You're probably looking for MF_DEFAULT.
It does not appear to be possible.
The internal state for the currently selected item in the menu can't be set. Using the MF_HILITE or HiliteMenuItem does not set the currently selected item, it only sets the visual style.
As a work-around, I have used a popup ListBox instead, which has all the features I need.
GUI: should a button represent the current state or the state to be achieved through clicking the button?
I've seen both and it sometimes misleads the user. what do you think?
The label on the button should reflect what the button does, i.e. it should describe the change the button makes.
For example, if you have a call logging system a button should say "Close Call" and the user can click it to close the call. The button should not have the label "Call is Open" and the user clicks to change the call status as that's very counter-intuitive, since the button is effectively doing the opposite to what it says on it.
In my opinion the label - and so the function - of a button should rarely, if ever, change. A button is supposed to be a like a physical button and they usually only do a single thing. (There are a few exceptions like play-pause on a media player where it's OK for the button label/icon to change, but at least this is copying a button from a real physical device.)
To carry on the example from above, I would say usually you would want two buttons, "Open Call" and "Close Call" and disable whichever one is not appropriate. Ideally you'd have a field elsewhere displaying the status of the call.
In summary, buttons are for doing things not for passing on information to the user.
The button should represent the action to be executed, not the state.
Some buttons are actions and are not ambiguous, like "Save", "Print" or "Enable user".
When a button represents a state that can be toggled, like Enable and Disable something, I do one of the following:
Change the button text, and make it always point to the state that will be achieved; (i.e. make the button point to actions, not states);
- Keep the button's text the same, but use one of those sticky buttons that will stay pressed, representing that the current state is "on" or "off". I prefer the former approach, though.
It should represent the action taken when clicking the button. States should always be presented by other means.
But I know what you mean. My car radio has buttons with text that shows the current state. It is really confusing.
This depends on the function which will be triggerd by the button click.
if the click changes the state of an entity i would suggest that the button represents the state the entity will enter after clicking the button
if the click triggers some kind of functionality the button should represent the function.
The appearance of the button is also a clue to its state. It should follow the standards of the environment if any exist (example, beveled edge / shadow appears on mouse click in Windows).