> OK, I now know how to reproduce this problem. Here's the code to create the environment: it creates a form, a main prg, a project and then builds and runs the EXE. The app will hang if you:
> - single click the tray icon
> - move the mouse over the shortcut menu items (starting at the bottom)
> - click empty area in the desktop to release menu
> --> after that, the shortcut menu nolonger appears when I click on the icon.
>
> Please test this scenario for me in VFP8 and confirm my observations. I will test this against VFP9 as well and report it to the VFP team if it's reproducable in VFP9 as well.
>

> CLOSE ALL
> CLEAR ALL
> ERASE systrayproblem.*
> * create form
> SET CLASSLIB TO HOME() + "Samples\Solution\Toledo\systray.vcx"
> MODIFY FORM systrayproblem NOWAIT
> ASELOBJ(aaa,1)
> aaa[1].AddObject("systray1", "systray")
> aaa[1].systray1.iconfile = HOME() + "Graphics\Icons\Misc\bullseye.ico"
> aaa[1].systray1.menutext="1;restore;2;start;3;stop"
> * create event code
> TEXT TO m.eventcode
> LPARAMETERS nMenuItemID
> DO CASE
> CASE nMenuItemID=1
> 	WITH _screen
> 		.Visible= .T.
> 		.WindowState= 2
> 	ENDWITH 
> CASE nMenuItemID=2 
> CASE nMenuItemID=3 
> CASE nMenuItemID=4
> OTHERWISE 
> 	WAIT CLEAR
> ENDCASE
> ENDTEXT
> * save event code
> aaa[1].systray1.writemethod("processmenuevent", m.eventcode)
> *
> aaa[1].writemethod("queryunload", "CLEAR EVENTS")
> * save scx
> KEYBOARD '{CTRL+W}'
> DOEVENTS
> * create main prg
> TEXT TO m.mainprg
> SET CLASSLIB TO HOME() + "Samples\Solution\Toledo\systray.vcx"
> PUBLIC goScreen
> goScreen=CREATEOBJECT('ScrEvents')
> BINDEVENT(_screen, "resize", goScreen, "Scrresize")
> DO FORM systrayproblem
> * minimize to tray
> _screen.WindowState = 1
> READ EVENTS
> DEFINE CLASS ScrEvents AS custom 
> 	PROCEDURE scrresize
> 		IF _SCREEN.WindowState = 1
> 			_screen.Visible= .F.
> 		ELSE
> 			_screen.Visible= .T.
> 		ENDIF
> 	ENDPROC
> ENDDEFINE
> ENDTEXT
> * save main prg file
> STRTOFILE(m.mainprg, "systrayproblem.prg")
> MODIFY PROJECT systrayproblem NOWAIT
> _vfp.ActiveProject.Files.Add("systrayproblem.prg")
> _vfp.ActiveProject.Build("systrayproblem.exe", 3)
> * run exe
> run/n "systrayproblem.exe"
> 

> --
> Eric den Doop
> www.foxite.com - The Home Of The Visual FoxPro Experts

Just wanted to chime in here to confirm the same behavior. We have been searching for a way around the problem for a few weeks now and have found that using your Foxitray.ocx does not have the same 'issues'. It appears to be something in the API with foxpro 'going to sleep' and not waking up until a mouseover event occurs on the fox window (i.e., if it was minimized you get it back up somehow and as soon as the mouse 'goes over' the form the event fires - which is of course slightly too late). We see the same 'sleep' behavior after 5 minutes of minimizing the form - and the same clicking on menu but not selecting issues - just strange stuff.

The one issue with FoxItray.ocx that we would like to see addressed is that it isn't 'up to date' with the latest systray style of handling tooltips - ie, longer tips that wrap to more than one line and, of less concern, the baloon style - I'm sure there's more 'compatibility' stuff but that's what we have run into (it works but we wish we could put longer tips...)

There's also a FOXTRAY.ocx (not to be confused with FOXITRAY) found on the Universal Thread downloads that doesn't have these problems either - but has other limitations. So it seems that activex controls bypass the problems. You might want to brush off FOXITRAY.OCX and do short rewrite! :)

Thanks for confirming that we aren't going crazy Eric,


Steven Supinski
Senior Software Developer
The American Contractor
ssupinski@theamericancontractor.com