Page 1 of 2
Strange issue with transported applications
Posted: Fri Feb 21, 2020 8:51 pm
by wriedmann
Hello,
in all my VO applications I'm using a dynamic menu (no more menu editor), and it works very well including shortcuts.
The same menu works also well in VO applications moved to X# (and it worked also in the Vulcan version), but in both applications the hotkeys don't work anymore.
In a small sample application the hotkeys work, but they don't work anymore in my applications that use my class library and the bBrowser.
This is an issue where I have lost days over the last years, and every time I have stopped searching because I could not afford it to loose more time.
Now, a customer asks for working hotkeys and I have to deliver this functionality.....
Has anyone had a similar issue and could point me in any direction where I could search?
Wolfgang
P.S. in the attached small sample the hotkeys are working so the functionality itself should work
Wolfgang
Strange issue with transported applications
Posted: Fri Feb 21, 2020 11:55 pm
by Chris
Hi Wolfgang,
You say that in a small app, it works ok. what happens if in that small app you add a window with bBrowser, does it still work? And what if you add your class library?
If it starts happening after adding your library, then maybe start removing things from it, until the problem again stops happening, so you know what was causing it. Are you using a BeforeDispatch() method in your class library?
Strange issue with transported applications
Posted: Sat Feb 22, 2020 7:23 am
by Karl-Heinz
Hi Wolfgang,
it´s hard to believe, but it seems that a shellwindow resize triggers the DynMenuAcceleratorKeys Destroy() method ! Simply add the DebOut32() call, resize the window and watch the output.
Code: Select all
METHOD Destroy()
//p Destroy the keys
//s
DestroyAcceleratorTable( SELF:hAccelerator )
DebOut32 ( "Destroy DynMenuAcceleratorKeys" ) // <-------------
SUPER:Destroy()
RETURN NIL
redgards
Karl-Heinz
Strange issue with transported applications
Posted: Sat Feb 22, 2020 7:24 am
by wriedmann
Hi Chris,
thank you for your answer!
Even adding (and opening) a window with a bBrowser control or adding my class library does not stop the hotkeys.
I have searched my entire projects and could not find any call to BeforeDispatch().
I have now migrated my "Empty" application - the base application on which I'm basing all my VO applications. And even in this application the hotkeys do NOT work.
I have now started to remove things from this application (mainly the WLibDlg lib that contains a lot of small dialogs I use everywhere) - and finally the hotkeys started to work - but only a few times - then they stop working, sometimes after the first time, sometimes after a 7 or 8 times they have worked.
I'm searching....
Wolfgang
Strange issue with transported applications
Posted: Sat Feb 22, 2020 7:33 am
by wriedmann
Hi Karl-Heinz,
thank you very, very much!
Resizing the ShellWindow immediatly stops the working of the hotkeys!
This is reproducible even in my small test application.
The strange thing is that this was the case with:
- Vulcan compiled GUI libraries and Vulcan compiled application
- Vulcan compiled GUI libraries and X# compiled application
- my own version of the X# compiled GUI libraries
- the GUI libraries delivered with the latest X# version.
I would never have been arrived at that conclusion!
You are really Mr. GUI classes!
Wolfgang
Strange issue with transported applications
Posted: Tue Feb 25, 2020 7:46 pm
by wriedmann
Hi Karl-Heinz,
I have now searched further trying to solve this issue.
The strangest thing is that on my machine the DestroyAcceleratorTable() is only called upon the ShellWindow close, but after the first resize of the ShellWindow the shortcuts stop working immediatly (maybe I have enough memory to don't let the GC kick in).
But I have now copied the ShellWindow class to my sample application (renaming it to XShellWindow), and have played with the part of the Dispatch() method where WM_SIZE is handled:
Code: Select all
case WM_SIZE
super:Dispatch(oEvt)
if self:__AdjustClient()
if IsClass(#OleObject)
hMDIChild := ptr(_cast, SendMessage(self:Handle(4), WM_MDIGETACTIVE, 0, 0L))
if (hMDIChild != NULL_PTR)
oDocApp := __WCGetWindowByHandle(hMDIChild)
if (IsInstanceOf(oDocApp, #__DocApp)) .AND.;
(IsInstanceOf(oDocApp:owner, #DataWindow))
//PP-040915 Issue 12961
if IsMethod(oDocApp:Owner, #__UpdateActiveObject)
Send(oDocApp:Owner, #__UpdateActiveObject)
endif
endif
endif
endif
return 0L
endif
return self:EventReturnValue
If I comment the part after the __AdjustClient() call, leaving this code:
Code: Select all
case WM_SIZE
super:Dispatch(oEvt)
if self:__AdjustClient()
return 0L
endif
return self:EventReturnValue
the shortcuts keep working even after every resize.
It is very strange because even the presence of the line
without leaving any other code in the of the "IF" breaks the shortcuts.
Please see here my test application:
Maybe someone like Chris or Robert can solve this miracle....
Wolfgang
Strange issue with transported applications
Posted: Tue Feb 25, 2020 8:13 pm
by Chris
Hi Wolfgang,
Seems to be working fine here. Please try again with tonight's new build, possibly it was a bug that's fixed now.
Strange issue with transported applications
Posted: Wed Feb 26, 2020 5:16 am
by wriedmann
Hi Chris,
no change here, unfortunately (It would be a strange coincidence since this is a looooong standing issue, even in pure Vulcan code.).
Run my sample app - you can resize how often you like, Ctrl+M will continue to work.
Then remove the comment // from line 407 in XShellWindow prg and the corresponding "endif" in line 419.
Run the application. Most of the time the Ctrl+M will work after the first resize, but never after the second resize of the shell window.
IMHO this part can safely be removed from the code because there will be no OleObject class in the transported GUI classes.
Wolfgang
Strange issue with transported applications
Posted: Wed Feb 26, 2020 8:03 am
by Chris
Hi Wolfgang,
Oh right, thanks, I see it now. All that IsClass() is doing regarding this problem, is that it triggers the garbage collector to do a collect, because of the many objects it creates, searching for the class in every assembly in the references list. You can reproduce the same thing by completely deleting the Dispatch() method and just issuing a GC.Collect() somewhere in the app, after this is done, shortcuts do not work anymore.
So apparently it's some kind of object getting completely out of scope (not stored anywhere) and collected by the GC when it kicks in, resulting on something not working. I will have a look a little later to try and find which object that is and then make sure it is stored in a global or similar. But do you really need all this very low level class in order to have dynamic menus? Do the standard classes from the VOSDK not work well in this aspect?
Strange issue with transported applications
Posted: Wed Feb 26, 2020 8:10 am
by wriedmann
Hi Chris,
the dynamic menus work also without that - but unfortunately then no shortcuts are available.
I have to admit that I had received the DynMenu class many years ago from someone else, and I'm using that for at at least 15 years in my VO applications.
Dynamic menus are a must because I build them based on the current user and/or application configuration (specially in my standard ERP application no customer has all functionalities active).
Wolfgang