Page.capture Issue


Recommended Posts

I've isolated a UI hang to using the page.capture() function, with HD resolution 1920x1080 on a pretty complicated summary page with hundreds of components. When I don't use the function call, the program works great. With the function call, the UI is either much slower or just will stop responding for (unusably) long periods of time. I've been using it to create a jpg that I then ftp to my website for remote monitoring. I'm running it on a Windows7 3GHz Core i7 64 bit with an SSD drive and 8GB of RAM so horsepower is not the problem. It looks like the recommended approach to this is to use DAQConnect, but I don't want to have to recreate the screens, and it didn't look like it will just post a screen shot (and it looks like it would add up to expensive over time, and I have my own SQL Server database with gazillions of data points). So, I tried using one of the myriad screen captures to save a screen shot and it looked like that was going to work fine, but then when I tried it on the target system which I always connect to with windows RDP, if the session is disconnected, the screen cap is black. The other problem is that the screen capture grabs other windows, and I really want a main summary window posted to the site even if a user is looking at one of the detail windows. So, if it worked better, the page.capture would be perfect. Any thoughts? Hmmm, Maybe run a second instance of DAQFactory using the broadcast data and run the capture in there so it doesn't kill the main one? Fix the page.capture to run at a lower priority than the user interface?

Link to comment
Share on other sites

I think there is a PrintPDF() function not noted in the help files...

It can spit out a "screen caputre" really fast and not hang DF...You may have to redesign a few of your screen components, but it is a great function...

Here is a quote from the post -

As for printPDF, there are other forums around with details, but basically its printPDF(pageNames, filename, xres, yres). It does not support all screen components, but does support things like text, tables, and graphs, which makes it useful for reports. It is not documented because its basically a feature that was never completed and isn't polished, kind of like the OOP stuff. It works fine as long as you understand the limitations.

Example -


Page.PrintPDF("MyPage", "C:\MyPage.pdf", 10, 30)
[/CODE]

Try it out! HTH!

Link to comment
Share on other sites

  • 3 months later...

The pages I had were too complicated for PrintPDF to work. I finally solved the problem by creating a second ctl file that read all the necessary files from a SQL server database that is populated periodically from the main program. It cycles through all of about 50 pages, does a page capture and FTP upload to a website, then starts over. It uses a lot of compute power and seems to hang if the network drops off for a while so that it is trying to run captures but cannot finish the FTP upload of them. Meanwhile it does work as long as the network (wireless in my case) stays working, and if it crashes or hangs, it doesn't take the control system with it.

Link to comment
Share on other sites

You might consider using the command line ftp or an sftp tool instead of the built in DAQFactory FTP. Use system.shellexecute() to trigger the FTP. The nice thing about this is that you can do all 50 pages in a single call. With command line ftp, you can create a text file that lists all the files and commands, and then put just the name of that file in the command line instead of trying to list all the files in the command line.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.