MarvinSketchForm Focus

Hi Victor,

I am using the MarvinSketchForm dialog, or more precisely the derived class you suggested a while ago for more fine tuned control, for editing reaction schemes in my ELN application. Now it occurrs to me, that after the dialog (no matter which variant)  with the displayed sketch opens, the contained sketch pane is not fully focused. Thus, when the user presses e.g. Ctrl-A to select everything, nothing happens. Only after clicking into the sketch pane it seems fully focused and receieves key events (while doing so, also the border brush of the Window changes to indicate actual focus). - Therefore: Is there way, maybe in the derived control, to achieve full sketch pane focus when the dialog opens? I tried several things in the OnActivate procedure, but without any success. Thanks for any help.

Hi Stefan,

please try to use:

sketcher.Value.requestFocus(); to regain the focus in the peer.

I slightly modified the reflector parts (ParentField):

https://www.chemaxon.com/forum/viewpost35742.html#35742

 

Viktor

Thanks Vicor, but I already tried sketcher.value.RequestFocus(), at least in the OnActivated procedure of the form, but without success. - Concerning your code changes to the derived form: Could you be so kind to specify what ecaxtly you changed? Its not obvious to me at first glance. Thanks!

 else {
if (field.Name == _name) {
return field;
}

this block was added.

interesting since the editor is focused in my demo project, the difference can be that you add a structure to it?

Whn does it loose the focus? Maybe later then this event comes in.

Best try to load a sample structure / reaction into the editor when opening it, otherwise it's impossible to test keyboard input like ctrl-A. The toolbar buttons all highlight in the editor when moving the mouse over them, but no keyboard input is received before clicking into the dialog content ...

I see the problem now. Win32 API always helps, I think.

[DllImport("user32.dll")]
private static extern IntPtr SetFocus(IntPtr hWnd);
[DllImport("user32.dll")]
private static extern bool SetForegroundWindow(IntPtr hWnd);
[DllImport("user32.dll")] 

var frame = new ParentField<javax.swing.JFrame>(baseEditor.Value, "_parentFrame");
var handle = ikvm.awt.NetComponentPeer.GetControlHandle(frame.Value);
SetForegroundWindow(handle);
SetFocus(handle);

SetForeground window is activating the window, SetFocus puts the keyboard focus into that window even if it is in a separate thread.

Yes, this works now, keyboard input is handled just fine. - However, it is not possible anymore to close the dialog using its Close icon, or the OK or Cancel buttons, since they don't respond anymore on mouse clicks ...

In your code there should be a bug then, since how these couple of WinAPI lines could influence the mosue handlers?

It still works to me : OK, Cancel, X on the form.

 

Here's my code, which activates the editor as desired, but is locking the form's exit controls in my case. I maybe should mention that I use thedialog from a WPF application, if this makes any difference ...

DllImport("user32.dll")> _
Private Shared Function SetForegroundWindow(hWnd As IntPtr) As Boolean
End Function
<DllImport("user32.dll")> _
Private Shared Function SetFocus(hWnd As IntPtr) As IntPtr
End Function

....

Protected Overrides Sub OnActivated(e As System.EventArgs)

MyBase.OnActivated(e)

Dim baseEditor = New ParentField(Of MarvinEditorControl)(Me, "_editor")
mSketcher = New ParentField(Of ChemAxon.marvin.beans.MSketchPane)(baseEditor.Value, "_content")

Dim frame = New ParentField(Of javax.swing.JFrame)(baseEditor.Value, "_parentFrame")
Dim handle = ikvm.awt.NetComponentPeer.GetControlHandle(frame.Value)

SetForegroundWindow(handle)
SetFocus(handle)

End Sub

Uploaded the ptototype please check. Yes it is imaginable that WPF makes it wrong.

Thanks for your code, it allowed me to pinpoint the source of my problem - I didn't use the setSettings flag in the OnActivate procedure, which until now didn't have any negative impact, but caused the trouble now. After implementing it everything works just fine.

So that's solved, thanks a lot!

 

Is the using the CustomEditor still the best/only way of achieving the proper focus when opening the MarvinSketchForm dialog in WPF?

 I am now using .FocusEditor (no more Window handles) in the OnActivated procedure of my CustomEditor. I havent tried outside custom editor, which I still use for other reasons.

There are still high level focus issues - thus, after closing the editor dialog, the window of the main application disappears behind all other windows present on the desktop. I could work around this by passing the main application window to my  Marvin class before opening the editor, and then activating it again programmatically when the editor closes. Not exactly nice, but it works.

Thanks Stefan for the answer!

Yes,  the main problem is that ikvm = java to dotnet simulation is not perfect for WIndows message loop architecture. In this way Java gui model runs in a different thread from the main WPF, WIndows Forms gui thread.

By the way my solution was to simulate better focus handling in Marvin OLE to use Windows hooks and tried to generalize when to react the activation of the parent gui element.

Maybe in the future we have 3 possible options to follow up:

 - checking ikvm if they fix the java - windows gui thread incompatibility

 - we try to introduce such a workaround with hooks

 - custom WIndows forms, WPF gui should be  implemented over the basic Editor (this requires a massive rework on java side => maybe next year we can start this ultimate solution, that is our plan)

 

in the meantime please try to make your users satisfied with smaller workarounds.

Thanks,

Viktor

One more thought re Custom Editor,

now as far as I know Stefan managed to build in the NativeEditor property to avoid using reflective code.
We managed to improve it to expose the internal editor object as a generic object property, if you need it you can reference the jChem .NET API dlls to access in a typed way (type casting to the native type from object).

 

 

Thank you very much for your answers - I hadn't noticed the .FocusEditor method being available in 5.6. I managed to get proper focus by just handling the Activated event on the MarvinSketchForm and accessing the (protected) editor field via Reflection which I could then use .FocusEditor on.

So yes, proper focus can actually be obtained without the use of the CustomEditor :)

Victor mentioned some of the problems associated with ikvm. Just as an idea, there are other ways to convert Java into native .NET, which additionally might produce are 'more native' .Net code. The demo of the product below served me extremely well for C# to VB.NET conversions, and they also offer it for Java to C# (or VB.NET) conversions. Who knows, maybe its worth to have a quick look at it. 

http://tangiblesoftwaresolutions.com/Product_Details/Java_to_CSharp_Converter.html

Regards, Stefan

Thanks Stefan,

however I would be suprised if this convert knew the gui related translation.

Viktor