Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Retrieve images from EXE
Message
From
29/01/2009 09:16:19
 
General information
Forum:
Visual FoxPro
Category:
COM/DCOM and OLE Automation
Environment versions
Visual FoxPro:
VFP 9 SP1
Miscellaneous
Thread ID:
01250756
Message ID:
01378078
Views:
37
>Hi Cesar,
>
>If the libraries and the images are compiled into the same EXE, you can use FILETOSTR to load the image into a string. Then you can pass this string to an API function that loads the image from memory. In any case, right now, I'm using the following code to load embedded images. Copying the file into the temporary directory isn't that much of a performance hit:
>
>  If ADir(laFile,Addbs(GetEnv("TEMP"))+JustFname(m.lcImage)) == 0
>  	StrToFile(FileToStr(m.lcImage),Addbs(GetEnv("TEMP"))+JustFname(m.lcImage))
>  EndIf 
>  loImage = _Screen.System.Drawing.Image.FromFile( ;
>    Addbs(GetEnv("TEMP")) + JustFname(m.lcImage) ;
>  )
>
Hi Christof,

After the discussion in this thread, we finished adding the following verification in the xfcBitmap.FromFile() method, in order to allow it to load images embedded in an EXE:
IF FILE(m.tcFileName) AND EMPTY(SYS(2000,m.tcFileName))
   ** File is an embedded resource
   m.lqBinary = FILETOSTR(m.tcFileName)
But this is not working, because System.App cannot "see" the embedded files from the EXE, so, neither FILE() nor FILETOSTR() functions do not work in this case.


This way, we should inform the GdiPlusX users to use the method "FromVarbinary(FILETOSTR(lcFile))" if they need to use embedded images, instead of using FromFIle(lcFile)


I also searched deeply in Lisa Slater's blog, but got no good news...
http://spacefold.com/lisa/post/2007/08/16/SP2-Sedna-FFC-ReportListener-Beta-Info.aspx

You can't cross-call between APP/EXEs. If you want an Xbase listener to "see" a built-in file, such as a JPG or an FRX you want to swap-copy, you need to build that listener into the same APP/EXE as the file you want it to see.

This is not a new limitation, and it's certainly not report-specific. But it's going to be more and more significant with this LoadReport feature in play. So I expect to see more of you building in your _ReportListener.VCX to your app, and getting friendly with it as a class library, rather than relying on _REPORTOUPUT as a separate app.





Anyway, I thought we could still try to find out a workaround for this...

Any ideas ?
Previous
Reply
Map
View

Click here to load this message in the networking platform