Locate a docx file into a grid table 1

[eyeshield21]

what i want is if a user clicks/ right click on one of the data on the grid
opens a specific docx file.

 

[vgulielmus]

Store the file name with its (full) path into another column(s) of the grid's underlying table, and ShelExecute() it, in the click / right click event

Respectfully,
Vilhelm-Ion Praisach
Resita, Romania

 

[Scott24x7]

What you need to do is shell execute to make that happen.

In whatever you have has as your "SET PROCEDURE TO"

Include the following code:

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)

Then in the [Click, or Right Click or Double Click - Whichever event you want it to "fire" on]

lcLaunchFile = '"'+SYS(5)+SYS(2003)+ALLTRIM(Table.Filename)+'"'
*
SHELLEXEC(lcLaunchFile)

Where the "lcLaunchFile" string sets up the fully qualified path to your docx document. (Actually this works with ANY document on your system, it will use the "default" program for that file type to launch it... PDF, JPG, DOC, DOCX, DWG, whatever).

The "ALLTRIM" Call above assumes you've saved the filename with any "additional" path data to the location. SYS(5) and SYS(2003) add the current drive and directory to that.. but that's just how I do it. If you've store the fully qualified path already, then you just pass the SHELEXEC call the field/variable name, and watch the magic.


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[eyeshield21]

sir scott... cant understand where to put the first code you gave..
could you be more basic..im little bit new here..and thanks

 

[Scott24x7]

Hi eyeshield,
Is ok, we've all be new, and the SHELLEXEC is not highly intuitive.
When your application starts, you probably have some .PRG file that runs first, sometimes it might be called STARTUP or something similar.
Usually there, or sometimes in other places you will have a line that reads:
SET PROCEDURE TO <somefile.prg>
By doing this, you can save routines that you use over and over in your application. If you don't have one, I suggest, start one (I call mine simply "common.prg"). Then as I create routines that I want to call from forms or controls, I can simply say:
MyProcedure(parameters) or lReturnVal = MyProcedure(parameters) if I am expecting something to be returned.

The key is, you want a reference to this "PROCEDURE" file pretty early in your application, so that it's available as early as possible as the application launches. VFP will then understand the calls you make (and it gets added to the "CODE" tab in your project.

If you do that, then the code I gave you above will just "work"
Notice that the first line is called "PROCEDURE SHELLEXEC". That is my "name" for the "Shell Execute" concept... What Shell Execute does is interacts with Windows OS and passes the OS the name of a file (or some other "command" for lack of a better word) that the OS recognizes, and then "Does It". Shell Execute can be used to launch files (based on type as you are looking for) or launch your browser to some URL, or even cause your email system to open a message with a recipient. It's very powerful, because it just "hands off" to the OS something that you want it to do. In essence what this does for what you are seeking is the same as double-clicking on the file in the directory.

Hope that helps a bit. The code of Shell Exec is not like "VFP" code because it's not... it's an interface into the OS.


Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[eyeshield21]

i have main.prg file where i put the 2nd code then
on the right click event of the grid table i put the second code.

when i run the main.prg and rigth click the gris table, nothing happens sir..
am i doing right here sir?..

 

[Scott24x7]

eyeshield,
The first block of code should probably be in your MAIN.PRG, but there should be some command in your startup that says: SET PROCEDURE TO MAIN.PRG which can't be IN the MAIN.PRG.
If you have it there, you're probably in the right place.

Now, the second block of code, you want to place in the RightClick event (if you want the Right Click to fire it), of the Grid Object (so don't put it on the column or field in the grid). You also need to have the fully qualified path so if you're just copying my example, it won't work... I assume in this case that the "table.filename" has only the file name and path identifier within the "known" directory structure. (which is why I add SYS(5) - current drive and SYS(2013) - current directory. Then I save the docs into various directories under that. You will have to make sure that you manage the fully qualified path to it.

You can test it interactive doing the following:

At the command Box issue:

SET PROCEDURE TO MAIN.PRG

Then issue: SHELLEXEC(<fullpath+filename>) to your document.

For example:

SHELLEXEC("F:\MyApp\DATASTORE\DOCUMENT\Worddoc.docx")

Your DOCX word document should then launch automatically.
Once you prove you have that working, then you just need to get the data passed from your right click in your grid to look like that too (which is what my 2nd example tries to illustrate).
It's tricky, but stick with it, you'll get it.



Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[JRB-Bldr]

As was said above - we were all New to FP/VFP at one point in time so your questions are welcome here.

However it might be worth your time to spend some time with the Free Online (or downloadable) VFP Tutorial videos at:
[URL unfurl="true"]http://www.garfieldhudson.com/FreeVideos.aspx[/url]

They will most certainly not cover ALL of the various topics you can encounter, but they do help understanding at a Foundation level.
Of particular interest might be the videos about:

Creating a Form Manually​

Building a Simple Application (Parts 1 - 6)​

Good Luck,
JRB-Bldr

 

[TamarGranor]

Usually there, or sometimes in other places you will have a line that reads:
SET PROCEDURE TO <somefile.prg>
By doing this, you can save routines that you use over and over in your application. If you don't have one, I suggest, start one (I call mine simply "common.prg").

I couldn't disagree more with this advice. Procedure files are unnecessary and a pain to work with. Code that's needed only in certain forms or classes should be built into those forms or classes at the appropriate level of the class hierarchy. Method code should very rarely call UDFs; mostly, it should call other methods, whether of the same object or of other cooperating objects.

Code that is viewed as an extension of the language should go into individual PRG files in a folder that's in the execution path.

Tamar

 

[eyeshield21]

Thanx..i already test it and it worked when i input the DIR manually on the shellexec.
what i dont understand is this code: '"'+SYS(5)+SYS(2003)

do i have to change that sir?
what to put inside the parenthesis?

 

[eyeshield21]

i just remove tht and it worked..tnx

 

[Scott24x7]

Hi Tamar,
I agree with you, my point was to get him working quickly, and some of the nuance is difficult when you have no idea how they otherwise have their application structured. But in this case, I would put it in the procedure file and make it globally available, as SHELLEXEC is highly useful in a great deal of places. It's hard to balance sometimes when you sense someone is inexperienced how to guide them in this forum... so I try to fix the user not the problem... that's their responsibility.

Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[Scott24x7]

eyeshield,
The SYS(5) and SYS(2003) are to provide information about the current directory location. A practice that I (and others) use is only to keep the file name, and minimal directory information saved with the file name in the table. This makes for moving the application around a lot easier. SYS(5) gives the current drive letter. So if you "hard code" your path "C:\MyApp\MyPath\MyDocStore\filename.docx" if the whole program gets copied to another drive (very common when moving from Dev to Test to Production) you have to strip the "C:" off either by replacing it with a new drive letter, or change the path to something that can be found later.
What I do dates back to my Fox2 days, which is to have environment paths set that are global that can be reference used to build fully qualified paths. The only way to ALWAY be certain you get the right location is to fully qualify the path. To do at run time, you take advantage of things like SYS(5) which gives you the drive letter and SYS(2003) which gives you the path that the application has currently set with the "SET DEFAULT TO <pathname>" command (or even CHDIR within code, if it gets manipulated that way).

These calls make it so you don't really care what or where they are, as you use them to create the fully qualified path at run time, based on where the application sees itself.

So do you need them? That depends on your application... and how you've set it up to manage and handle these things.
I sense that you are inexperienced with Fox and probably development overall. You will likely make a lot of mistakes, but don't worry so much about that... it's part of your learn curve. More importantly, just get in and give it a try, and then understand WHY you get the result that you get. You'll figure it out then over time.



Best Regards,
Scott
ATS, CDCE, CTIA, CTDC

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

 

[Olaf Doschke]

Well, it's not the best idea to always use SYS(5)+SYS(2003) for the movable path. Docs or data shouldn't go into the program files folder but into system folders like common appdata. For workgroups and organizations you put them into the network in a file share and that will not move when the exe is installed different and so the current path differs. Also the current path could be somewhere else when Code CDs somewhere. If you want something to depend on the EXE directory you can use SYS(16,0), if you want something to depend on the location of a DBC then you can get its path with DBC() when the DBC is open and the current database, if something has a relative path to a DBF you can use DBF("table") when the DBF is open. All these have the EXE, DBC or DBF file name in them, but you can take JUSTPATH() of them. What's always an option is to make a path configurable via some config.dbf or ini or xml. Storing it extra is a good practice, if there is such a base path. But if users are allowed to pick files from anywhere it's even not wrong to store it in the data.

That could have been described instead just naturally assuming it would work out for you, too, but you also can look up any code in the VFP help or you execute it in the command window and see what it gives via ? printing to the screen, for example ? SYS(5) and ? SYS(2003). Actually putting SYS(5)+SYS(2003) in front of a filename only is what VFP does automatically anyway, so it's not needed at all. Eg USE somtable.dbf is 100% equal to USE SYS(5)+SYS(2003)+"sometable.dbf", including the way VFP would also search along all paths you tell it via SET PATH in case it does not find sometable in the current directory. In case your data includes a path prefixing it with SYS(5)+SYS(2003) is even dead wrong, as you have two paths put together, which of course does not work out. The current directory is the current directory, not any fixed directory like install path. As already said it changes with CD or the equivalent SET DEFAULT and also the working directory setting of shortcuts, that makes it movable, if you want it, but can also be wrong, if the current dir is changed to something different than the path of documents should be. SYS(5)+SYS(2003) is important when it comes to giving the path of a document to eg ShellExecute or a Word.Application instance, as these external to VFP functions don't know about VFPs current directory. Of course that is also only needed, if the filenames you pass in to these external modules are in or relative to the current directory, what base dir to prefix is a case by case decision, that you need a prefix in these cases is non optional.

Bye, Olaf.