Faulty behaviour of subitem-DropDowns when moving main form

1. offizieller Beitrag

    Hi,

    we are using the OCX in Microsoft VisualFoxpro 9 SP2 with great success. There is only one glitch, that under this environment is shown by the OCX. This behaviour is not shown of the very same OCX when used under C# or C++

    The windows used by the subitems of the toolbars or panels are not "connected" to their "parentbutton". Under VFP9 i can move the mainform when such a subitem-window is open. The subitem-window is NOT closed (as it is under c#/c++), but stays open at its position where it was when it was initiated.

    This looks like this:

    ColorPicker when clicked on Button
    [Blockierte Grafik: http://www.betreuung.de/grafik/img1.png]

    After moving the main window that holds the ocx by dragging the window with the mouse.
    [Blockierte Grafik: http://www.betreuung.de/grafik/img2.png]

    This issue happens to ALL subitems from the toolbar or the other Panel-SubItems.

    I know that VFP9 is something special because the forms of a VFP9 application have all the same HWND as the MainWindow of VFP itself.

    I suspect that TD binds itself with it's events to the main form which is not triggered by VFP "subforms". It should be better to attach itself to the HWND of the OCX itself. Because the ocx-window itself is moved by VFP during moving the mainform you should be able to detect the movement of the window.

    If needed i could provide an example EXE which shows that behaviour.

    Hope you could provide a solution for this.

    Best regards
    Michael

    LOGO Datensysteme GmbH
    http://www.betreuung.de | http://www.datensysteme.de

    Hi Julian,

    a possible workaround could be that i trigger something from my form.moved-Event.

    Is there any method, property, command ... in the wpdllint object i should call to trigger a "refresh/repaint" of the current content including closing or moving the opened dropdown-windows?

    I can do a win-sendmessage to something when you tell me what and with what message i shall call...

    Perhaps you have a chance give the hwnd of the dropdown-window so i can "destroy" it myself. Or you add a possibility like "wpDLLint.CloseAllDropdowns" so that regardless of the current status of possible Dropdowns all these windows can be closed programmatically.

    Just my 5cents on this... :)

    Best regards
    Michael

    Great Idea...

    I will give it a try... I'll do a sendmessage() to the HWND of the OCX with WM_KILLFOCUS and have a look what happens...

    But WM_KILLFOCUS doesn't feel quite right for this (even if it might work), because the point is: You are not lossing focus here, because the Mainform just moves due to MouseOperations. That wouldn't count a a FocusLost-event.

    When i setfocus to another VFP.Objekt (and therefore TD is loosing it's focus) the submenu closes right away and works perfectly.

    Perhaps that's the point. There is no KILLFOCUS because TD should actually keep the focus when the mainform ist "just moving around"...

    Anyway, I'll have a test an report back what's happening.

    Best regards
    Michael

    Oooops.

    I did not need it until now... There is no HWND Property on the ocx...

    Is there any way to get the HWND of the actual Editorwindow of TextDynamic? I'll need it obviously to PostMessage the WM_KILLFOCUS to it...

    Perhaps one of the functions available can return a HWND and i just did not find it in the helpfile...

    Any Idea anyone?

    Thanks
    Michael

    Hi everybody,

    until Julian finds a generic solution, i found a workaround for VFP users that work pretty good. So here for those who are interested the Workaround:


    1.) Insert another CommandButton onto the Form holding your TD-object. Place it OffScreen so that it is never visible (like at Postiion -100,-100) AND set the TABSTOP Property to .FALSE. (so it is not reachable to users using TAB-key)

    2.) In the FORM.Moved Event put the following code (adapt to your objectreferences)

    Code
    IF this.ActiveControl.BaseClass="Olecontrol"     IF this.ActiveControl.OleClass="WPTDynInt.WPDLLInt"            this.oDummyCmdButton.SetFocus()     ENDIF ENDIF

    We double-Check if the focused Object is actually the TD OCX itself, because only then we'll have to do the focus-manipulation. And due to the fact that we move focus when this is true, the setfocus() is done only once. This is important, because the Moved() - Event comes quite often during moving the form.


    3.) In the KeyPress-Event of the Dummy-CmdButton put the following code (again adapt to your objectref)

    Code
    * Put the Focus back to the actual TD-OLEObjectthisform.rtf.rtf.SetFocus()* nKeyCode and nShiftAltCtrl are parameters of the KeyPress-Eventif nKeyCode=93 AND nShiftAltCtrl=1        * Special Treatment for Win-ContextMenu        DODEFAULT(nKeyCode,nShiftAltCtrl)ELSE        NODEFAULT        =api_SendInput(nKeyCode,nShiftAltCtrl)ENDIF

    KeyCode=93 AND nShiftAltCtrl=1 happens only when in this situation the WinMenu-Contextmenu-Key is pressed. We hand this off to the DefaultKeyHandler of VFP.
    Otherwise we stop handling the Keypress (=NODEFAULT) and stuff the whole Keypress-Stuff back into the Windows-Handling.

    Here is the code for the API_SendInput() - Function:


    Until Julian finds a way to give us the actual HWND of the OCX this code actually triggers a true WM_KILLFOCUS because of the Focus-Moving to another VFP-Object and puts the focus right back if a key is pressed after moving the form.

    When we have the HWND this code will be obsolete and one should simply send a POSTMESSAGE(hwnd, WM_KILLFOCUS) to the OCX.