VFP Buffering and Shellexecute()

[char_m]

I'm hoping someone can give me some insight on this.

I have an existing application that I am migrating from single-user to multi-user and am using buffering for the first time.

One of my forms uses a shellexecute() command to allow the user to open an existing .pdf file that is saved as a field in a table

It works fine with the single-user version, but the mulit-user version causes the most bizarre computer hang I have ever seen...it may, or may not, throw an error that says "the application was unable to start correctly" with a variety of 0xc0000nnn errors, then proceeds to turn the screen black, moves the start line from the bottom to the top (and sometimes back to the bottom), intermittently shows part of my VFP screen, and eventually hangs so my only option is a hard re-boot. I've tried it with Nitro pdf and Adobe Reader so far with slightly different timing and flickering before it locks up the computer.

It is VFP 9 in Windows 7 pro any my code is identical between the single-user and multi-user versions....The single-user version works flawlessly with the exact same code and file.

Really confused...Help???

Here's the code I'm using:
--------
declare INTEGER ShellExecute in shell32 INTEGER handle,STRING @ oper,STRING @ ifile,STRING @ iparam,STRING @ ipath,INTEGER showcmd

lcFileName=this.Parent.sp_cfieldsource
lcFile=&lcFileName

=shellexecute(0,"open",lcFile,"","c:\",1)
--------
I have confirmed that the lcFile does contain the correct full path to the pdf to be opened

So far I have tried the following changes with no success:
=shellexecute(0,"open",lcFile,"","",1)
=shellexecute(0,"open",lcFile,"","",0)

Thanks...

 

[Scott24x7]

Try using this to replace your Shellexec routine:

PROCEDURE SHELLEXEC

LPARAMETER lcLink, lcAction, lcParms
*
lcAction = IIF(EMPTY(lcAction), "Open", lcAction)
lcParms = IIF(EMPTY(lcParms), "", lcParms)
*
DECLARE INTEGER ShellExecute ;
    IN SHELL32.dll ;
    INTEGER nWinHandle, ;
    STRING cOperation, ;
    STRING cFileName, ;
    STRING cParameters, ;
    STRING cDirectory, ;
    INTEGER nShowWindow
*
DECLARE INTEGER FindWindow ;
   IN WIN32API ;
   STRING cNull,STRING cWinName
*
RETURN ShellExecute(FindWindow(0, _SCREEN.caption), ;
                    lcAction, lcLink, ;
                    lcParms, SYS(2023), 1)

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

"Everything should be made as simple as possible, and no simpler."

 

[Olaf Doschke]

Since Shellexecute creates a new process, this has to do nothing at all with VFP, as you already checked the path is correct, there's not much more you can do.
One slight change would be not throwing away the return value of ShellExecute, see

http://www.ml-consult.co.uk/foxst-26.htm

(scroll down to the last paragraph "did it work").

You likely will not get more information about the problem, if your computers crash with it.

Do you get similar behaviour when starting the PDFs from windows Explorer via double clicking on them? That actually also does the open action on the file, just like ShellExecute does.

Bye, Olaf.

 

[JRB-Bldr]

Since you are changing this application you might want to consider the following:

open an existing .pdf file that is saved as a field in a table

It is Not a good idea to store a document in a field within a data table.
You have a perfectly good place to store documents, its called a Windows directory.
Then in your data table you store the location and name of the document in the field within the data table so that your application can 'find' it and use it accordingly.

In that way to eliminate the MAJOR BLOAT that can occur with the documents themselves in the field.
Plus, storing a document is typically done in a Memo field which are not terribly reliable over the long-haul.
And, PDF file sharing (as long as the storage directory was globally shared) across multi-users would be much better.

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

JRB-Bldr,

advising not to store PDFs in General or Blob fields is good advice, but from the given code you can see this is nat what happens, only path/filenames are stored:

...
lcFileName=this.Parent.sp_cfieldsource
lcFile=&lcFileName

=shellexecute(0,"open",lcFile,"","c:\",1)

That plus char_m saying

I have confirmed that the lcFile does contain the correct full path to the pdf to be opened

means the data stored is just the path. We don't know what Parent.sp_cfieldsource is, but if lcFile is the final file name needed, then there can't be an error in that part. I just hope, char_m, you really inspected lcFile at that point via the debugger or Messagebox(lcFile) and not just looked at the data it comes from. Since this code doesn't show what happens in regard of lcFile and there is no direct lcFile = table.field, many things can go wrong on the way from the DBF field to the variable.

But not being suspicious in the first place and taking the given outset lcFile is a correct file name with full path of an existing PDF, in the end any error then has nothing to do with VFP, as it's the OS API ShellExecute failing, most probbably PDFs are broken. I've had errors due to fonts.

There are different DECLAREs in regard of string parameters of ShellExecute sometimes as byref parameter, sometimes as normal string, both will work, ShellExecute won't return changed parameter values, so @ (by reference) is obsolete, but your declaration of ShellExecute works in general, char_m, so there also is no cause in that aspect, which is the only VFP relevant connection here. You can try other DECLARES as given by Mike Lewis page on ShellExecute with VFP or by Scotts code. The only thing I noticed wrong in your experiments: You tried the last parameter with 0, that means hiding the new window created by ShellExecute. Some PDF software might override that and show anyway, but you want the PDF to show, so values making sense here would be 1 (show normal window) or 3 (show maximmised window). Also see

https://msdn.microsoft.com/en-us/library/windows/desktop/bb762153(v=vs.85).aspx

- that also names parameters differently and the declaration Scott made rather roots in MS official parameter naming than the declaration you found in your code. For general better references it pays to keep up with norms and official declarations, but it doesn't change the functionality, if you give parameters different names, you just find less references in the internet searching with non normal names.

Bye, Olaf.

 

[Mike Lewis]

I'm a bit puzzled. You say you have the same code in both the single- and multi-user version, yet the single-user version works fine; it is only the multi-user version that crashes.

So the question is: What is different between the two versions?

What ever those differences are, what you should be doing is to start with the single-user version, then gradually make the changes for multi-user one step at a time, and see at which point the problem starts to occur.

I suspect that the answer has nothing to do with it being multi-user, but rather some other discrepancy that has crept in during the conversion process. But that's only a guess, of course.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

One thing, which could differ is sotware installations in other but the single client it works on. And what could be the culprit is new PDF files having problems, as I once had with fonts. Then this is just coincidence and has nothing to do with the single vs multi user change. I also doubt this is the reason, as the only things you need to care about from the VFP side are:

1. Your ShellExecute declaration works. You can check that eg via ShellExecute(0,"open","notepad.exe","","",1) or ShellExecute(0,"open","C:\HaxLogs.txt","","",1) (or any txt file).
2. Your File is existing. You might check that by visual inspection or via ADIR(laDummy,lcFile)=1

If these two things are OK, the only difficulties might be the path only working from one computer (eg no share or drive letter mapping exists on other clients), but in that regard I would simply expect file not found errors and no hard crashes. I'd say the problem is within the PDF files, they are not so self contained as often thought of, you can embed fonts, you can depend on Windows installed fonts.

Bye, Olaf.

 

[GriffMG]

I would try copying the target file from it's live location to an exclusive one on you local drive with a specific name (constant)
and open only that file.

Removes any chance that someone else is looking at the file.

Could this be an antivirus issue?

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​