On 2017-08-11 14:55, Kevin J Cully wrote:

We used Citrix at a healthcare company I worked at around 2005. Basically everyone came in to an office, just to telecommute into our hosted servers that was in a city 30 minutes north of our office. It was a valid approach to better securing workstations.

I was doing a good bit if VFP9 at that time and there wasn't much (if anything) that I had to do to the application. I tended to make the buttons bigger because with the remote-aspect of running the app, the double+clicks didn't always "take". We called it "having to triple+click" ... or ... "click it like you mean it!" It had more to do with Windows and the nature of following the mouse movement from local to remote.

They had portable profiles however. They didn't wipe the image as there were valid reasons that people would have customized desktops and customized software installations, even if the Windows was remote.

This approach saved us on PC purchases as well. We could buy pretty minimal PCs as the real horsepower was in the Citrix VM'd PCs.

Hth, Kevin

Thanks for sharing that, Kevin. If you had to design an app for the "wipe daily" scenario, how would you do it? Personally, I think Andy Kramek's idea (years ago!) of using meta-data that had code in memo/text fields may work well for this scenario. Andy's approach may not have been good for source code control (as per one detractor), but the idea of self-updating easily was on-point, imo.

We don't have to wipe our apps every night either.

On Mon, Aug 14, 2017 at 8:49 AM, Kevin J Cully kjcully@cherokeega.com wrote:

One of the benefits of VFP is that you might be able to run the application from a central server. Nothing to be installed on the workstation itself? Might be worth testing.

Another approach is to have the workstations run a "stub" that creates a directory on the workstation and copies the VFP runtimes, and EXE locally with enough to get it running. Tonight the workstation is wiped. Tomorrow that same stub is run and the VFP app is copied locally again. Again, might be worth testing out. Nowadays, the VFP runtime files are tiny compared to the .NET runtimes! :O :D

Good luck.

-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@mbsoftwaresolutions.com Sent: Friday, August 11, 2017 10:02 PM To: ProFox Email List Subject: RE: VFP9SP2 apps on Citrix

On 2017-08-11 14:55, Kevin J Cully wrote:

...

We used Citrix at a healthcare company I worked at around 2005. Basically everyone came in to an office, just to telecommute into our hosted servers that was in a city 30 minutes north of our office. It was a valid approach to better securing workstations.

I was doing a good bit if VFP9 at that time and there wasn't much (if anything) that I had to do to the application. I tended to make the buttons bigger because with the remote-aspect of running the app, the double+clicks didn't always "take". We called it "having to triple+click" ... or ... "click it like you mean it!" It had more to do with Windows and the nature of following the mouse movement from local to remote.

They had portable profiles however. They didn't wipe the image as there were valid reasons that people would have customized desktops and customized software installations, even if the Windows was remote.

This approach saved us on PC purchases as well. We could buy pretty minimal PCs as the real horsepower was in the Citrix VM'd PCs.

Hth, Kevin

Thanks for sharing that, Kevin. If you had to design an app for the "wipe daily" scenario, how would you do it? Personally, I think Andy Kramek's idea (years ago!) of using meta-data that had code in memo/text fields may work well for this scenario. Andy's approach may not have been good for source code control (as per one detractor), but the idea of self-updating easily was on-point, imo.

[excessive quoting removed by server]

I did something similar - nothing clever, just a batch file that copied the executable from the server to the work stations

Laurie

On 14 August 2017 at 15:46, Dave Crozier DaveC@flexipol.co.uk wrote:

I have a general purpose "Loader" app that loads the .exe from the server onto the local workstation in a pre-defined folder and runs it. This means that updating the .exe on the server is simple as you are sure that it is never open by anyone. In addition I can send the loader instructions to unload the local .exe if there is a workstation server update due. It unloads the local "exe" and sits waiting for a signal to upload the newer updated .exe off the server. And it has saved hors of trouble finding out who has the application open on the network.

Dave

-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@mbsoftwaresolutions.com Sent: 12 August 2017 03:02 To: ProFox Email List profox@leafe.com Subject: RE: VFP9SP2 apps on Citrix

On 2017-08-11 14:55, Kevin J Cully wrote:

...

We used Citrix at a healthcare company I worked at around 2005. Basically everyone came in to an office, just to telecommute into our hosted servers that was in a city 30 minutes north of our office. It was a valid approach to better securing workstations.

I was doing a good bit if VFP9 at that time and there wasn't much (if anything) that I had to do to the application. I tended to make the buttons bigger because with the remote-aspect of running the app, the double+clicks didn't always "take". We called it "having to triple+click" ... or ... "click it like you mean it!" It had more to do with Windows and the nature of following the mouse movement from local to remote.

They had portable profiles however. They didn't wipe the image as there were valid reasons that people would have customized desktops and customized software installations, even if the Windows was remote.

This approach saved us on PC purchases as well. We could buy pretty minimal PCs as the real horsepower was in the Citrix VM'd PCs.

Hth, Kevin

Thanks for sharing that, Kevin. If you had to design an app for the "wipe daily" scenario, how would you do it? Personally, I think Andy Kramek's idea (years ago!) of using meta-data that had code in memo/text fields may work well for this scenario. Andy's approach may not have been good for source code control (as per one detractor), but the idea of self-updating easily was on-point, imo.

[excessive quoting removed by server]

Richard, No problem.... It can be set up for any VFP .exe app to use and is driven via a small DBF table which says which app to load, where to put it on the local machine etc... You can run many apps through the loader at once and it also passes parameters onward from your shortcut to the main app.

I'll package it up and put it onto Ed's page.

Dave

-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Richard Kaye Sent: 14 August 2017 15:59 To: profox@leafe.com Subject: RE: VFP9SP2 apps on Citrix

Having a great deal of respect for your VFP chops, is your loader something you can share, Dave? I'm always curious about the mechanics of these types of things.

--

rk

-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Dave Crozier Sent: Monday, August 14, 2017 10:46 AM To: profoxtech@leafe.com Subject: RE: VFP9SP2 apps on Citrix

I have a general purpose "Loader" app that loads the .exe from the server onto the local workstation in a pre-defined folder and runs it. This means that updating the .exe on the server is simple as you are sure that it is never open by anyone. In addition I can send the loader instructions to unload the local .exe if there is a workstation server update due. It unloads the local "exe" and sits waiting for a signal to upload the newer updated .exe off the server. And it has saved hors of trouble finding out who has the application open on the network.

Dave

[excessive quoting removed by server]

On 2017-08-14 11:04, Richard Kaye wrote:

Sounds great. I'm pretty sure Michael B posted one here a while back, too.

I did, but that one's dated, and although it probably still works, I redid it years ago with the code I just posted. I'll also post that update to the ProFox downloads page; I think it's all there in those 3 routines.

On 2017-08-14 10:59, Richard Kaye wrote:

Having a great deal of respect for your VFP chops, is your loader something you can share, Dave? I'm always curious about the mechanics of these types of things.

--

rk

Here's a copy/paste from FabNet, called from my Main.prg:

PROCEDURE CheckForNewerVersion() LOCAL lcServerVersion as String, lcLocalVersion as String, lcLANFile as String, loData as _dataVersions OF .\progs_dataVersions.prg, ; loShell as _ShellExecute OF HOME()+"ffc\environ.vcx", loRec as Object, llUpdateLAN as Logical, llMissing as Logical, lcLANVersion as String LOCAL ARRAY laInfo[1] lcLocalVersion = _screen.cversion && SetVersion() lcLANFile = ReadINI("General","SetupFile",'') loShell = NEWOBJECT("_ShellExecute", "_environ.vcx")

*** mjb 09/18/2015 - updated for Admin user, plus grabbing EXE from cloud *** mjb 02/17/2016 - DEV NOTE: This needs work yet to grab latest installer from web database and put in lcLANFile location; will finish later IF NOT EMPTY(lcLANFile) THEN WAIT WINDOW NOWAIT "Checking master source for latest update..." loData = NEWOBJECT("_dataVersions",".\progs_dataVersions.prg") *** mjb 02/17/2016 - moved this next IF block outside the next IF block after that so as to get lcLANVersion for the 3rd IF block IF FILE(lcLANFile) THEN && see if LAN version is the cLatestVersion lcLANVersion = GetVersion(lcLANFile) CopyInstallerLocally(lcLANFile,ALLTRIM(lcLANVersion)) && mjb 05-11-16 llUpdateLAN = loData.ConvertVersionToNumber(lcLANVersion) <> loData.ConvertVersionToNumber(oUtils.oClient.cLatestVersion) ELSE && update LAN with latest from web database llMissing = .T. llUpdateLAN = .T. ENDIF *** mjb 02/17/2016 - added iNetwork = 1 to only run this IF block for MBSS Cloud clients IF oUtils.iNetwork = 1 AND loData.ConvertVersionToNumber(lcLocalVersion) < loData.ConvertVersionToNumber(oUtils.oClient.cLatestVersion) THEN && verify update exe's version is as expected *** mjb 12/28/2015 - added check to only run this for PRODUCTION run IF oUtils.oConnection.Descript = "Production" AND llUpdateLAN THEN *** mjb 12/18/2015 - for now, just alert them IF llMissing THEN MESSAGEBOX(oUtils.Get_Translation("Your network installation file appears to be missing. This is not critical; this just allows you to have your computers update from a common spot on your network rather than the internet. Contact MBSS if you need assistance."),16,oUtils.Get_Translation("Update file missing")) ELSE MESSAGEBOX(oUtils.Get_Translation("Your network installation file (" + ALLTRIM(lcLANFile) + ") appears to be outdated (version " + ALLTRIM(lcLANVersion) + "). Contact MBSS if you need assistance."),48,oUtils.Get_Translation("Update file out of date")) ENDIF && llMissing ENDIF && llUpdateLAN ENDIF && loData.ConvertVersionToNumber(lcLocalVersion) < loData.ConvertVersionToNumber(oUtils.oClient.cLatestVersion)

IF FILE(lcLANFile) THEN lcServerVersion = GetVersion(lcLANFile) IF NOT EMPTY(lcServerVersion) THEN IF lcServerVersion > lcLocalVersion THEN IF MESSAGEBOX(oUtils.Get_Translation("An update is available for this application (version") + " " + lcServerVersion + "). " + oUtils.Get_Translation("Do you want to upgrade?"),4+32+0,oUtils.Get_Translation("Upgrade available.")) = 6 THEN && launch setup from server and quit this app *** mjb 02/17/2016 - changed next line to lcLANFile instead of lcFile loShell.ShellExecute(FULLPATH(lcLANFile)) RELEASE loShell oUtils.Shutdown_System() && mjb 05-13-16 was QUIT ENDIF && msgbox = 6 ENDIF && lcServerVersion > lcLocalVersion ELSE SET STEP ON ENDIF && NOT EMPTY(lcServerVersion) ENDIF && FILE(lcLANFile) ENDIF && NOT EMPTY(lcLANFile) ENDPROC && CheckForNewerVersion()

FUNCTION GetVersion(tcFile as String) as String *** mjb 09/24/2015 - created to quickly check version # on files LOCAL ARRAY laInfo[1] LOCAL lcVersion as String, loException as Exception TRY lcVersion = '' IF FILE(tcFile) THEN AGETFILEVERSION(laInfo,tcFile) lcVersion = laInfo[4] ENDIF CATCH TO loException lcVersion = '' ENDTRY RETURN lcVersion ENDFUNC && GetVersion(tcFile as String) as String

from my data object: FUNCTION ConvertVersionToNumber(tcVersion) as Number LOCAL lnNumber as Number, liMajor as Integer, liMinor as Integer, liRevision as Integer, liMultiplier as Integer IF NOT EMPTY(tcVersion) THEN liMultiplier = 10000 liMajor = VAL(GETWORDNUM(tcVersion,1,".")) liMinor = VAL(GETWORDNUM(tcVersion,2,".")) liRevision = VAL(GETWORDNUM(tcVersion,3,".")) lnNumber = (liMajor * liMultiplier^2) + (liMinor * liMultiplier^1) + (liRevision * liMultiplier^0) && could have skipped liMultiplier^0 but kept for logical flow ELSE lnNumber = 0 ENDIF && NOT EMPTY(tcVersion) RETURN lnNumber ENDFUNC && ConvertVersionToNumber(tcVersion) as Number

I have a similar system except that the .exe resides on the workstation and the server. When the app is started it actually runs the loader first which checks the version number of the local exe and the server exe. If the server exe is newer then it copies it across to the workstation which means that it is only copied when necessary instead of every time.

John

John Weller 01380 723235 07976 393631

-----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Dave Crozier Sent: 14 August 2017 15:46 To: profoxtech@leafe.com Subject: RE: VFP9SP2 apps on Citrix

I have a general purpose "Loader" app that loads the .exe from the server onto the local workstation in a pre-defined folder and runs it. This means

that

updating the .exe on the server is simple as you are sure that it is never

open

by anyone. In addition I can send the loader instructions to unload the

local

.exe if there is a workstation server update due. It unloads the local

"exe"

and sits waiting for a signal to upload the newer updated .exe off the

server.

And it has saved hors of trouble finding out who has the application open

on

the network.

Dave

Nihil nove sub sole.

On Aug 14, 2017 9:36 PM, mbsoftwaresolutions@mbsoftwaresolutions.com wrote:

On 2017-08-14 13:49, John Weller wrote:

...

I have a similar system except that the .exe resides on the workstation and the server. When the app is started it actually runs the loader first which checks the version number of the local exe and the server exe. If the server exe is newer then it copies it across to the workstation which means that it is only copied when necessary instead of every time.

John

John Weller 01380 723235 07976 393631

Yep...that's what I do too. Conditional checking.

[excessive quoting removed by server]

On Mon, Aug 14, 2017 at 4:50 PM, John Weller john@johnweller.co.uk wrote:

...

Nihil nove sub sole.

There is nothing new under the sun.

I hired one of my best employees at Blackstone because she had modified an elegant loader, lifted from the pages of FoxPro Advisor, with proper credits in place, in 1997.

On 2017-08-11 16:32, Bill Anderson wrote:

Mike

I think SYS(602) exists because of these types of applications...just make a note of it.

Interesting. My Win7Pro 64-bit laptop returns 256 for OS(10). Didn't think this would be considered having a Terminal Server present?

Thanks for the tip. I don't recall ever reading about SYS(602).