ProFox October 2019

profox@leafe.com

40 participants
47 discussions

Welcome, new guy!
by MB Software Solutions, LLC 08 Oct '19

08 Oct '19

Well there's something that rarely happens around here...you notice a new guy! Welcome, cctbysteve(a)gmail.com aka Steve in Florida! Tell us about your travels with the Fox! -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

1 0

[NF] This is incredible....command prompt refusing my command to change directory!
by MB Software Solutions, LLC 08 Oct '19

08 Oct '19

Am I having a senior moment?!?? See screenshot: https://www.screencast.com/t/ur5534H9KT I am trying to navigate to a different folder on my dev drive and Windows says "No!" ??? -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

6 9

Southwest Fox 2019: Keynote announced
by Rick Schummer 08 Oct '19

08 Oct '19

The Southwest Fox 2019 Keynote Presentation will stream using Facebook live video starting at 7:00 pm MST (10:00 PM EDT), Thursday, October 24. Kevin Ragsdale is presenting the keynote session titled "The Fox Family: A Whimsical Celebration of FoxPro and the FoxPro Community". Rick White Light Computing, Inc. www.whitelightcomputing.com 586.254.2530 - office

1 0

Re: VFP App Startup Program
by Charlie Coleman 07 Oct '19

07 Oct '19

Unfortunately I do not have your original code Gene (if you showed it in an earlier email). If you know your config files differ between your startup and your main, it might be an issue. I'm assuming you have tried compiling the config.fpw into the .exes to see what happens (you can include it under the 'other' files). But I cannot vouch for the situation as my config.fpw files pretty much the same regardless of the app. I have not used the RUN /N, I usually use WinExec. You need to register the function, here is a block of code I use to declare it: *-- Declare the Win API function for running other executables *-- The uIntCmdShow can be: *-- SW_HIDE - 0 *-- SW_FORE_AND_MAX - 3 *-- SW_MINIMIZE - 6 *-- SW_DEFAULT - 10 *-- ....??? *-- Make sure and put a CHR(0) on the end of the parameters *-- cExecutable = 'f2pdfgen.exe' *-- cParameters = ' 1 2000 c:\dev\form2\data\ f2newpdf' + CHR(0) *-- cCommandString = cExecutable + cParameters *-- x = WinExec(cCommandString, 0) DECLARE INTEGER WinExec IN Win32API STRING @lpszCmdLine, INTEGER uintCmdShow Anyway, I'm not sure why you would have a problem with the updater updating the main .exe. If the update is failing the mainexe may still be running? But if the only way to run your main .exe is by running the updater that should not happen. I did put a piece of code in my updater app that would write a 'special file' - the main exe looks for the existence of that special file and if it is not found, it immediately exits. If it does exist it erases it and continues on its merry way. But one thing I had to do was not try to update the updater exe. I fixed that by not trying to update the updater .exe until I exited the main .exe - e.g. AFTER the CLEAR EVENTS in my main .exe. I also download my updates to a holding folder, not directly to the .exe files. I did that partly for testing/tracing at first, but then I saw the 'copy to update' process was so fast that there was no reason to change to direct downloads. After I saw that, doing my above process (updating the updater only when my main .exe exited) became very easy. So, to sum up, - my updater downloads (or copies from a server) all needed updates into a holding folder. - if the main .exe was part of those updates, it copies the .exe from the holding folder over the main .exe and then deletes the main .exe from the holding folder (for me, the holding folder is subfolder under the main .exe folder). - the updater app creates a 'special file' to show that it has been executed - then I run the main .exe and let the updater app exit out - in the main.exe I check for the 'special file' - if it exists, it is erased and the .exe continues, if it does not exit, the .exe immediately exits (do not pass GO, do not collect $200) - then in the main .exe I have code after the CLEAR EVENTS (e.g. aka in the ON SHUTDOWN code, or whatever) that looks to see if there is a new 'updater.exe' waiting in the holding folder. If there is, I copy that, delete it from the holding folder, and then continue on to let the main.exe exit. I have never had "timing update" problems with the above. I have a feeling the above design would work using "RUN... /N" as well. HTH, -Charlie On Mon, Oct 7, 2019 at 4:49 PM Gene Wirchenko <gene(a)shaw.ca> wrote: > At 13:11 2019-10-07, "Tracy Pearson" <tracy(a)powerchurch.com> wrote: > >Gene, > > > >How you launched the 2nd executable from the 1st executable may have been > a > >cause. > >The VFP RUN command will block if you don't use the /N clause with it. > > I did use run /n. It works like a charm with my one-level loader. > > >The ShellExec API should have returned control allowing you to exit the > 1st > >executable. > >There are a couple of API's that will wait for the 2nd executable to > return > >before continuing. > > > >The VFP RUN command the CMD window to run the 2nd executable. ShellExec > will > >not. > > So how does this make a difference? > > > It is bothersome trying to debug this, because I can not see > what is happening. Because the loaders are .exe programs, I do not > have the benefit of the debugger, etc. > > I have been wondering if having two VFP .exes running at once > is an issue. (Is there a conflict between config files?) > > [snipped previous] > > Sincerely, > > Gene Wirchenko > > [excessive quoting removed by server]

1 0

RE: VFP App Startup Program
by Tracy Pearson 07 Oct '19

07 Oct '19

Gene, How you launched the 2nd executable from the 1st executable may have been a cause. The VFP RUN command will block if you don't use the /N clause with it. The ShellExec API should have returned control allowing you to exit the 1st executable. There are a couple of API's that will wait for the 2nd executable to return before continuing. The VFP RUN command the CMD window to run the 2nd executable. ShellExec will not. HTH, Tracy -----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of Gene Wirchenko Sent: Friday, October 04, 2019 7:03 PM To: ProFox Email List Subject: VFP App Startup Program Hello: I have seen discussions about this at various times, but I have not ever seen details. You have an app which might be updated and want to have that happen automatically. In my case, it is a VFP .exe, and I wrote a program to handle that years ago. What about if the startup program needs to be updated? Since there is a change (the first since) in that, I wanted to write a version that would update the update program, too. Somehow, it did not work. And since there is less debugging information available when debugging a .exe, I ended up giving up on it after some trouble. My thought was to have two programs: cbs2run.exe would check cbs2run2.exe if it needed updating (and maybe update), check cbs2.exe (the app) if it needed updating (and maybe update), then run cbs2run2.exe. cbs2run2.exe would check cbs2run.exe if it needed updating (and maybe update), then run cbs2.exe. The reason that I had two programs is so that cbs2run.exe would quit running and be overwritable. Even inserting a 5-second pause before trying to overwrite cbs2run.exe in cbs2run2.exe did not work. I got some very inconsistent and confusing results. Was I overlooking something? If so, what? Sincerely, Gene Wirchenko [excessive quoting removed by server]

2 1

AW: VFP App Startup Program
by juergen＠wondzinski.de 07 Oct '19

07 Oct '19

Hi Gene, normally your Starter programm just runs the main program, after checking for updates, and then quits itself. The starter cannot update himself, thus another program / task has to do this. The easiest way would be to first install a new main program, which checks the starter for version, and optionally does the update for the starter program. Thus the two can update each other :) wOOdy -----Ursprüngliche Nachricht----- Von: ProFox <profox-bounces(a)leafe.com> Im Auftrag von Gene Wirchenko Gesendet: Samstag, 5. Oktober 2019 01:03 An: ProFox Email List <profox(a)leafe.com> Betreff: VFP App Startup Program Hello: I have seen discussions about this at various times, but I have not ever seen details. You have an app which might be updated and want to have that happen automatically. In my case, it is a VFP .exe, and I wrote a program to handle that years ago. What about if the startup program needs to be updated? Since there is a change (the first since) in that, I wanted to write a version that would update the update program, too. Somehow, it did not work. And since there is less debugging information available when debugging a .exe, I ended up giving up on it after some trouble. My thought was to have two programs: cbs2run.exe would check cbs2run2.exe if it needed updating (and maybe update), check cbs2.exe (the app) if it needed updating (and maybe update), then run cbs2run2.exe. cbs2run2.exe would check cbs2run.exe if it needed updating (and maybe update), then run cbs2.exe. The reason that I had two programs is so that cbs2run.exe would quit running and be overwritable. Even inserting a 5-second pause before trying to overwrite cbs2run.exe in cbs2run2.exe did not work. I got some very inconsistent and confusing results. Was I overlooking something? If so, what? Sincerely, Gene Wirchenko [excessive quoting removed by server]

4 3

VFP App Startup Program
by Gene Wirchenko 04 Oct '19

04 Oct '19

Hello: I have seen discussions about this at various times, but I have not ever seen details. You have an app which might be updated and want to have that happen automatically. In my case, it is a VFP .exe, and I wrote a program to handle that years ago. What about if the startup program needs to be updated? Since there is a change (the first since) in that, I wanted to write a version that would update the update program, too. Somehow, it did not work. And since there is less debugging information available when debugging a .exe, I ended up giving up on it after some trouble. My thought was to have two programs: cbs2run.exe would check cbs2run2.exe if it needed updating (and maybe update), check cbs2.exe (the app) if it needed updating (and maybe update), then run cbs2run2.exe. cbs2run2.exe would check cbs2run.exe if it needed updating (and maybe update), then run cbs2.exe. The reason that I had two programs is so that cbs2run.exe would quit running and be overwritable. Even inserting a 5-second pause before trying to overwrite cbs2run.exe in cbs2run2.exe did not work. I got some very inconsistent and confusing results. Was I overlooking something? If so, what? Sincerely, Gene Wirchenko

1 0

VFP9SP2 DBC -- update trigger
by MB Software Solutions, LLC 04 Oct '19

04 Oct '19

I've got a client with a wonky situation where the data (for some unknown reason) gets "blanked out" (not deleted, mind you...just some fields set to blanks). I wanted to add an UPDATE trigger so that I could get some sort of historical update accounting to help me hone in on where the problem might be. If I've used triggers in VFP then I've totally forgotten how to use them. (Keep in mind that I haven't used VFP DBFs since 2004! This is an app I took over for one of our former buddies, Jeff Johnson, after he passed away.) I use triggers in MySQL/MariaDB all the time. There, I've got the record object in the OLD and NEW object keywords. Looking at the CREATE TRIGGER Command in VFP help makes me think that the table is the currently selected work area, and as such, I could just do a SCATTER MEMO NAME oRec and then use that oRec variable to insert values into a separate table. Wanted to bounce this off the community prior to my testing that theory tomorrow. Does that sound right? Tips for a better way to do it? I was going to create a "shadow" copy table and just basically do the following in a database stored procedure: * assuming current work area is the table where the UPDATE trigger is firing LOCAL oRec as Object SCATTER MEMO NAME oRec INSERT INTO MyTable_COPY FROM NAME oRec IF isblank(oRec.Field1) and isblank(oRec.Field2) and isblank(oRec.Field3) then && alert MBSS of problem scenario that should never happen but this must be the bug happening!!!! DO EmailMBSS ENDIF Can it really be that easy? tia, --Mike --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

5 4

[NF] LastPass
by Paul Newton 03 Oct '19

03 Oct '19

Hi all I know that many of use and recommend LastPass so (i) Can I use LastPass Free indefinitely, (ii) does the free version work across multiple devices (I believe it does) and (iii) will it work with multiple browsers (e.g. Chrome and Firefox) on the same device ? Many thanks Paul Newton --- StripMime Report -- processed MIME parts --- multipart/alternative text/plain (text body -- kept) text/html ---

6 8

Bad style, but any chance it would ever fail to update properly?
by MB Software Solutions, LLC 03 Oct '19

03 Oct '19

We've seen this before (and I did it 2 decades ago): REPLACE MyTable.MyField with SomeOtherTable.SomeField The implication is that "replace the MyField value in the MyTable table." But if one doesn't use the IN clause, will there ever be any chance that the update to MyTable.MyField would fail? tia, --Mike --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

3 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

ProFox October 2019