early versions of 4D used forms for multiple purposes: QUERY BY EXAMPLE IMPORT TEXT EXPORT TEXT MODIFY SELECTION DISPLAY RECORD PRINT LABEL
etc. most things were done using just table forms, with little to no code. --- now, instead of storing print settings in forms, you can simply use BLOBs https://doc.4d.com/4Dv17/4D/17.1/Print-settings-to-BLOB.301-4179598.en.html https://doc.4d.com/4Dv17/4D/17.1/BLOB-to-print-settings.301-4179628.en.html the BLOB contains standard (driver independent) values such as DEVMODE and DEVNAMES on Windows PMPrintSettings and PMPageFormat on Mac it also stores the printer name and printer specific values, which is why you may get 1 (the settings are successfully restored) or 2 (the printer names don't match, some model-specific values might be lost) as result status code. 2019/04/06 4:18、Ben Sokal via 4D_Tech <4d_tech@lists.4d.com<mailto:4d_tech@lists.4d.com>>のメール: A related question: Are particular printer drivers (like PDF Xchange for example) "linked" to individual forms? Documentation for to-bit printer plugin we use says: "...you have to integrate a 4D dummy form which stores the "PDFXChange" printer driver settings...." That is really the source of these print settings questions. We've had these forms for years but since we've also had seemingly random pdf problems, so I am wondering if some of our dummy forms have some bad settings in them. ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
