Beiträge von MMihelic

    The following statement was a show stopper for our use of the FireMonkey:

    Zitat

    Virtual machine and virtual execution environments (like Citrix) might pose a more significant challenge, as most of them do not support a GPU and not everything in FireMonkey can fall back to GDI+. This is not a FireMonkey specific issue, as other application platforms suffer the same problems.

    I think the source of this statement was the following paper: Discover FireMonkey, The Next Generation Business Application Platform by Marco Cantù

    Guess what our customers are using quite frequently... Citrix and Terminal Servers for client apps and virtualized servers for server apps.

    Try renaming the latest WPDF300W.DLL to WPDF300A.DLL and put it in the application directory instead.

    Julian has a long standing bug in the Unicode/ANSI DLL detection routine that gets triggered (at least) on Delphi2010 compiled executables.

    The filename of the PDF output file gets mangled. I am guessing that if you use API tracer (FileMon, ProceMon) you will see that your application is trying to create a file on the root of the drove on which you want the output PDF file. If you are running as an administrator take a look if there is a file "C:\C" on your C: drive (if that was the output drive) and rename it to *.PDF.

    --
    Regards,
    Matej.

    Unfortunately, this is not the only difference. I guess the other problem might come from the other change - TWPDFFieldDef.Mode "add 256 for UTF-8". Application compiled with D2010 previously using wPDF300A.DLL now requires wPDF300W.DLL.

    If I give to an existing build of the application a new wPDF300A.DLL the PDF will be created - but using the wrong filename (there are no Unicode chars in filename!) and all the PDF header properties are empty.

    It looks like you have broken the backwards compatibility of wPDF300A.DLL for Delphi executables compiled with the D2010.