How to Set Cursor Position in Gtk -Linux, Monodevelop

How to manage key pressings for special purposes in Gtk# TreeView?

I am no expert in GTK, in fact I have never worked with it. But I have played with standard Controls in order to trick them into a non-default behavior. I was especially modifying the Menu bar, which trapped all Input when the Alt key was pressed, but I needed the Alt key as a modifier for various interactions. So I can offer you some general advice about tricking your TreeView into what you need.

Question 1:

From what you describe, I suppose the default behavior would be to press Enter for a successful edit, and to leave the Cell to cancel the edit. This might be acceptable in many applications. Others (e.g. Microsoft Excel) tend to accept the edit even on leaving the cell. So I can understand that you want that behavior.

If there is no such built in behaviour, you can simulate the Action a user has to do to signal the TreeView to finish editing, e.g. pressing Enter. You can send a fake Key event using the approach described here or if GTK builds on WPF like here. The second approach is even more lowlevel as it really implants the fake key event in the windows event queue. I guess that should work in any case, as long as your platform is Windows. But I'm sure there are similar mechanisms in other OSes.

Then only AFTER that, translate to the next cell, TreeView gets the lost focus event, but it is no longer in edit mode and nothing should happen.

Question 2:

What I think happens is the following: A key is pressed, TreeView is not in edit mode, so ignores the event. You get the event, and set it in edit mode. But then the event will not return to TreeView, so no input is made any longer.

You could try above approach and manually re-send the key event. Another way is to capture the event earlier, then when TreeView processes it. In WPF there is often the PreviewOn* event (e.g. see here). so maybe there is such an event for your control?

You could also hook yourself even deeper. In WPF there is the InputManager.Current.PreProcessInput event which sits just above the windows message loop and lets you filter and process all kinds of inputs.

Here is a snipped from my code which may help you:

InputManager.Current.PreProcessInput += (sender, e) =>
{
    if (e.StagingItem.Input is MouseButtonEventArgs)
    {
        var earg = (MouseButtonEventArgs)e.StagingItem.Input;
        if (earg.RoutedEvent == Mouse.PreviewMouseDownOutsideCapturedElementEvent)
            OnPreviewMouseDownOutsideCapturedElement(sender, earg);
    }
};

For more lowlevel hooks see for example this question.

Good luck, and please comment, if you have more specific questions.

Get a mock Cairo::Context to test conditions on the path

Just create a cairo image surface with size 0x0 and create a context for that.

Cairo::RefPtr<Cairo::Surface> surface = Cairo::ImageSurface::create(
    Cairo::Format::FORMAT_ARGB32, 0, 0);
Cairo::RefPtr<Cairo::Context> context = Cairo::Context::create(surface);

Since the surface is not used for anything, it does not matter which size it has.

(Side note: According to the API docs that Google gave me, the constructor of Context wants a cairo_t* as argument, not a Cairo::Context*; this might explain the crash that you are seeing)

Related Topics