Fonte - thenextage.com/wordpress/
1. FExtractResource() looked promising but is only for Mobile
2. You can embed and use images (PNG, etc) easily. just referencing their names for using DLoadImage, but it doesn’t work with PDFs
3. Embedding the PDF in the EXE is easy, but since there is not a native function to extract them, it would require a couple of different Windows API calls to handle, which started making my head hurt.
I finally discovered that there is a little known feature of HF Classic files that lets you embed them in your executable and then the standard Hxxxx commands will access the files just like as if the HF was on disk.
So what I did was create a HF table that has a binary memo where I store the PDF. I then embed that HF table in my EXE. Then I use HReadxxxx commands to get the PDFs.
The last challenge was to use ShellExecute to display the PDF in acrobat etc. the PDF has to be on disk, so I created my own PDF viewer in WD, so that I could display the PDFs without ever writing them to disk.
I recently needed to embed several PDF files in our executable so we didn’t have to ship them individually with application and keep track of updating them separately. The original plan was to try to do something similar to what pcSoft does with the DLLs in the executable, where they “self-extract” with the first run. However I ran into a few issues.
1. FExtractResource() looked promising but is only for Mobile
2. You can embed and use images (PNG, etc) easily. just referencing their names for using DLoadImage, but it doesn’t work with PDFs
3. Embedding the PDF in the EXE is easy, but since there is not a native function to extract them, it would require a couple of different Windows API calls to handle, which started making my head hurt.
I finally discovered that there is a little known feature of HF Classic files that lets you embed them in your executable and then the standard Hxxxx commands will access the files just like as if the HF was on disk.
So what I did was create a HF table that has a binary memo where I store the PDF. I then embed that HF table in my EXE. Then I use HReadxxxx commands to get the PDFs.
The last challenge was to use ShellExecute to display the PDF in acrobat etc. the PDF has to be on disk, so I created my own PDF viewer in WD, so that I could display the PDFs without ever writing them to disk.
So let’s take a look at the demo application I put together for all of this.
This is a simple screen that displays a browse of our HF table that has the binary memo in it. The first two buttons allow you to add either a file, or an entire directory of PDFs to the HF table. This includes storing the PDF in a binary memo field. The Delete button is fairly self explanatory. The refresh button updates the binary memo using the current PDF located in the original location recorded when the file was first added. This is useful for updating the HF table after the PDFs have been updated. As I mentioned this system was created for distributing PDF help files with an executable, so with each release of the executable some of the help files are updated to cover new features, so its a simple matter to run the refresh button before generating the executable so that the latest PDFs will be included. Finally the view button is viewing the PDF using a “native” PDF viewer I created. Note: this viewer is actually displaying the PDF stored in the HF binary memo, not the physical file on the drive.
The layout for the HF table is very simple.
First there is a autonumbered id field, which all your tables should have after hearing Andy and I harp on that for years! Then the filename, and location are in separate fields. You could store them as one field if desired, but in my production application we are referring to the PDFs by their name so I need it as an independent field. And last is a Binary memo field to store the actual contents of the PDF file. This is a HF Classic table.
Now for the code. First a bit of project code.
If you read the help (which I KNOW you do!), you will discover that by default WinDev looks for HF classic files embed in the EXE first and then on disk, but for the sake of the developer that comes after me, I wanted to make this a little more obvious. So if we are in TestMode(), the Green Go button in the IDE, then I want to use the HF from the disk. That means that when I run via the GO mode I am updating the physical HF table. In my production application I have slightly different logic to handle this as I have a small help application that is only on the developers machine for updating the HF table.
The real magic happens when we are not in test mode, the hWDL constant says to look the the HF table embed in the library either your a WDL file or the EXE file. As mentioned this is actually the default access mode for HF classic tables, and if it doesn’t find it in embed it will search for it on the disk, so you have to be careful that you have really accomplished what you think you have when testing. We will discuss that more latter.
Let’s look at adding PDFs to the HF table. The code behind the Add Directory looks like this. The code behind Add a file is just a simpler version of this that doesn’t need to step through a directory so we will only look at the Add Directory code.
Line 1 turns on the hourglass, in case this is a large directory that could take a few moments to process. Line 2 opens the standard windows dialog to select a directory. If a directory was selected the real work begins with line 4 which uses the fListFile function to get a carriage return separated list of all PDF files in the directory. If there were PDF files in the directory the Line 6 begins looping through the list and adding them to the HF table. If you haven’t seen a For Loop like this before spend a few minutes studying it and reading the help files as it can be very handy. It takes a string of values separated by a character in this case a carriage return (CR) it places them into a single string (tmpFullFileName) one at a time with each pass of the Loop.
Line 8 and 9 use a few handy string functions from WX to separate the FileName from the Path.
Line 10 checks to see if there is already a record with this file name and if so it updates the record in lines 11-13, otherwise a new record is added via lines 15-18. The only line that we should really need to take a look at in that code is line 12 and 17. What they are doing is using another great WX function (fLoadBuffer) to load the physical PDF into the binary memo. This could be any physical file, so you could use this to store word docs, other applications, whatever you might need store inside your HF table.
When the Loop as completed Line 23 refreshes the table display, then we give the user a message to let them know it is done and turn off the hour glass.
At this point we have our physical HF table with the PDF stored in the binary memo. Before we take a look at my PDF viewer, lets look at how to embed this HF table in the EXE we are going to make.
I am sure there are several ways to do this via the IDE, but I tend to use the Project Explorer for most things. Notice in the project explorer there is a “Other” folder, anything that we add to this folder will be incorporated into our executable as a resource.
This opens the Windows file picker and lets you select files to add, and you can see in this screen shot that I have selected the 3 files that make up our HF table, the actual file (FIC), the Index (NDX) , and the Memo (MMO).
Afterwards the files are shown in my project explorer
Now we can generate the EXE
This takes you through several screens, I will assume you have made a WinDev executable before, so I will only mention a few items from this screens. First notice on the content of the EXE our HF files are shown.
For simplicity of this demonstration, and because I have UAC turned off on my system, I will set the directory of the data files to reside with the executable.
Also to make this demonstration easier, I will include the DLLs in the EXE
After a few more screens we have an executable. And if you run the executable and View one of the PDFs it will be displaying the PDF from the Binary Memo from the HF table that is embed in the EXE. If you don’t believe me and want to verify this, you can move the EXE to a different directory and even delete the HF table and the PDFs, and the EXE will still perform fine and display the records.
NOTE: a “downside” to this is that the HF tables that are included in your EXE are read only, you can not update them. Which when you think about it makes a lot of sense, as it would be fairly dangerous writing new data inside an EXE file while you are running it!!! This does provide yet another way to tell that we are actually using the embed HF table, if we try to add a file, we will get an error like this
Which again tells us the file is in read only mode because it is embed.
So that is all there is to embedding a HF table inside your Executable, and I could end the article now, but you know I always have to give you some bonus material. In our production app we of course wanted the user to be able to view the PDF files, originally when we were distributing physical PDF files we would use ShellExecute to accomplish that using whatever PDF viewer they had installed, the only problem with that is the files have to physically exists on the drive, which sort of defeats the purpose of our cool new ability. So I decide to create my own PDF viewer to display the PDF from the Binary memo field without ever writing the PDF to disk.
The code behind the view button is pretty simple. If a record is selected in the table, it performs an HReadSeekFirst to get the record and then calls my PDFViewer window pass the binary memo as a parameter.
The viewer is a simple window with a toolbar of useful buttons, and an image control.
The display mode of the Image is Homothetic without enlargement and the Anchoring is set to expand both by width and height.
The initialization code of the window, moves the passed binary memo into the Image control, and sets the zoom mode to fit by width.
The InitTittleBarandPageNumber procedure set the caption to the display both the current page # and the total number of pages. It also has some logic to enable/disable the page up / down buttons based on what page is being displayed. This is done as a procedure so that it can be called from all of the controls in the toolbar.
If you were expecting some fancy, complicated image/PDF manipulation code next then you haven’t been paying attention to me going on and on about how easy WX makes my life!!
Here is the code from the 3 controls that change which page is displayed. The Page up and down buttons and the page number edit control. As you see all they do is change the PageNumber property of the image control and then call the InitTittleBarandPageNumber function to change the caption and enable/disable the page up/down buttons.
So there must be some complicated code behind the zoom buttons at least, right? WRONG!!! If it seems hard in WX you are probably doing it wrong!!! Here is the code for all five zoom buttons.
Again all they are doing is changing the value of the Zoom property, it can’t get much easier than that can it?
And that is the all of the code of my “native” PDF viewer. Nothing fancy, but it sure is handy!.
Hopefully this has inspired you and got you thinking about how you could use this technique in your projects. Along with distributing PDF help files like we are doing, some thoughts that come to mind is perhaps distributing images that you want somewhat protected and don’t want the user to have direct access to the image files. You could also create a electronic catalog of products, that could be distributed as a single EXE file, even if your actually catalog uses several HF tables. Perhaps this could be used for some type of high end individual licensing of executable prior to them being shipped. And I am sure there are even more imaginative ways to use this technique, so be sure to come back and let us know what you used it for!!!
And as a final bonus, here is a link where you can download this entire project! http://thenextage.com/opensource/PDFHelp.zip
Uncle Pete’s Corner is webinar series on all things WX, to watch the watch the Uncle Pete’s corner webinar that is the companion to this article, and many other WX related webinars go to the WinDev US YouTube Channel and be sure to also join the WxLive – US Communityon Google+ to get notices about upcoming webinars. On the Google+ community you will find a active group developers discussing all things WX.
Pete Halsted - NextAge
Pete
Halsted has been developing custom business management applications for
small to medium-sized companies, since 1987. His focus is on
client/server, distributed and cloud based development utilizing WinDev,
WebDev, and PostgreSQL. Pete is a Clarion Certified Developer with 25
years in the industry, has spoken at several Developers conferences, and
provided Developer training and mentoring on a one on one basis. He has
served companies both large and small as Project Manager, Lead
Architect, Lead Developer and Chief Technology Officer. Pete is
currently living the beach life in Biloxi, MS with his wife and dog,
enjoying the freedom provided by cloud based technologies. Pete is
available for Project Management, Custom Design, Development, Training,
and Speaking assignments. For more information please visit www.thenextage.com or follow his blog at www.thenextage.com/wordpress
Nenhum comentário:
Postar um comentário