Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[James Klutho]

Edit July 22, 2017 - Updated the include file (now version 2)to be high dpi aware for the print preview dialog but I have no way to test it. Also, I explicitly defined parameters as BYVAL or BYREF.  Parameters that were FB arrays remained as is since they balked at this effort.

Edit July 23, 2017 - Updated the include file to version 3 and made modifications to the PowerPoint demo.  Removed the EZP_SetProcessDPIAware from the include file and put in the PowerPoint demo.  Tried scaling the control fonts in the dialog callback

I have been working on a print control in the spirit of DDoc for the last couple of months.  It is a wide-string utility which compiles in 32 or 64 bit in Freebasic for Windows and is in the form of an include file - much like GRD.  You might have a look at it to see if it is useful to you.  I have actually included some documentation with this one.  There are quite a few samples so hopefully you can figure out what I was trying to do with this project.  I think there are enough objects defined to be generally useful in set up pages for printing and previewing.

A couple of stumbling blocks I never solved. 1) Enumerating printers on a remote network.  For the life of me, I could not enumerated the network printers at work that I have access to except for the default printer.  These remote printers (except for the default) are not in the registry.  Some voodoo here I am not privy to. 2) Rotating bitmaps around there center and controlling where they end up.  The GDI+ matrices baffle me and I could not find any useful examples on the internet.  There were a lot of inquiries on the subject and the solutions offered were not generalized enough.  I'm sure Patrice know how this is done but my little brain is fried on the subject.

Anyhow, good luck to everyone.
Jim

[José Roca]

Looks very good. A couple of observations:

1) You should add  BYVAL or BYREF to all the parameters (there are many parameters without it). Otherwise, it will give errors if compiled with the option -w pedantic and will be broken if __FB_OPTION_BYVAL__ is set to -1.

2) It is not DPI aware. This makes a big difference in sharpness in the preview window and also the controls become minuscule if the application that uses it is DPI aware. See attached captures.

Regarding printers enumeration in a remote network, it can be done using WMI. I wrote a WMI class wrapper (CWmiCli), but I limited it to work with the local computer because I don't have access to a network and, therefore, I can't do tests.

[James Klutho]

Thanks Jose for your input.  I will rest for a week or so then tighten down some of the bolts you suggest.  Jim

[aloberr]

you is a large programmer because you proved reliable with POWERBASIC, I use your GRID and your PRINTPREVIEW, I also wrote a control GRID not badly, I do not find it for the moment in my archives. in addition Your printPreview is good, in the past I tried to do it, instead of storing the data in a document, a decided to draw directly on the pages by having a table of pages(control STATIC), I butted the fitting of these pages because certain drawings did not post a whole but very likewise, I could make ravel the pages of continuation, like in WORD.   

[James Klutho]

I updated the included file in the first post of this thread.

[Paul Squires]

Great work Jim! Print Preview control and Grid control are two of the most useful controls for most of my business applications.

[James Klutho]

Thanks Paul,Jose and aloberr

[José Roca]

Hi James,

You must remove the call to EZP_SetProcessDPIAware from EZP.inc. This call must be placed at the beginning of your application, if the application does not use the appropriate manifest.

In EZP_NewDialog you must also set the style DS_SETFONT and then add the font (scaled according the DPI scaling ratio) to the DLGTEMPLATE structure. Otherwise, the dialog will use the system font (8 points) and nothing will scale when you set the process DPI aware.

[James Klutho]

@ Jose

I tried to scale the fonts in the dialog controls but not in the way you suggested.  The DLGTEMPLATE thing is so confusing to me and I barely got it running as you probably remember from my plea for help on the Freebasic forum a couple of months ago.  Take a look at the new include file and WM_INITDIALOG message in the dialog callback to see how I scaled and set the fonts for the child controls with a SendMessage WM_SETFONT method which is the how I am use to doing it.  The PowerPoint demo is the test file I was using.

I don't have a high DPI monitor so I am flying blind to what you are seeing.

Thanks for your feedback as always.

Jim

[José Roca]

@James,

Put the call to SetProcessDPIAware in WinMain, not in a place where is not executed.

Code: [Select]

function WinMain ( byval hInstance as HINSTANCE, _
                   byval hPrevInstance as HINSTANCE, _
                   byval szCmdLine as zstring ptr, _
                   byval iCmdShow as integer ) as integer

 EZP_SetProcessDPIAware
 print EZP_IsProcessDPIAware   ' check if it has been set

In EZP_ControlAdd, you're using

Code: [Select]

IF hWnd THEN SendMessage hWnd, WM_SETFONT, SendMessage(cast(HWND,hDlg), WM_GETFONT, 0, 0), 0

but has you have not set the size of the font for the dialog in the dialog template, the call to WM_SETFONT, SendMessage(cast(HWND,hDlg), WM_GETFONT, 0, 0) will return NULL, that means that it is using the system font.

Code: [Select]

IF hWnd THEN SendMessage hWnd, WM_SETFONT, SendMessage(cast(HWND,hDlg), WM_GETFONT, 0, 0), 0
print "Font: ", SendMessage(cast(HWND,hDlg), WM_GETFONT, 0, 0)

See in the capture how small (half the size) appear the controls in my monitor.

Dialogs don't work like SDK windows. They scale automatically according the size of its font.

Maybe Pierre, that is the only SDK'er that I know that likes dialogs, can help you to properly fill the dialog template.

Almost nobody is paying the due attention to DPI awareness. One day they will regret it and ask for an "easy" solution. You know, there are always "easy" solutions to any problem. What happens is that SDK'er like to complicate things

[José Roca]

Add also BYVAL or BYREF to the parameters that don't have it or anybody will get many warnings when compiling with the -w pedantic switch.

Also be careful with INTEGER (I have ended never using it). It is not the same that with PB. In FB, INTEGER evaluates as a LONG when compiling with the 32 bit compiler and to a LONGINT (QUAD) when compiling with 64-bit. The equivalent to PB's INTEGER is SHORT, and the equivalent to WORD is USHORT.

[James Klutho]

Thanks for the feedback Jose.  The reason I used a dialog in EZP was that it was goal of the project to use a dialog that was not resource based.  I had never done that before.  I program pretty much for the heck of it.  One of these days I will no doubt get a high DPI system that will make catching these problems easier.   Misplacing the EZP_SetProcessDPIAware was a big OOPs as I was in a hurry.  I will correct it.  I will see what I can do to fix the dialog title.

Jim

[Paul Squires]

The application that I just wrote used the libharu pdf library to output my reports to. I then shellexecute to open the pdf using whatever default pdf reader is installed on the system. Looking at your code and documentation I now realize that in the long run I may have been better off adapting your code to my application as I would then have total control over the whole report generation, displaying, and printing process. I will take a closer look at your code and see if I can adapt it for my use and at the same time provide any code upgrades that I may notice.

[Paul Squires]

After looking through the code it gave me ideas on a different way to approach this print and print preview code.

I have prototype code working that creates each page via metafiles (CreateEnhMetaFile). Using this device independent approach I am able to send the GDI commands easily to the screen or printer (Charles Petzold actually had this code in the awesome "Programming Windows" book). It also allows creating everything in memory with having only one active device context so that there is not a substantial use of GDI resources. The non-current metafile pages can be saved as binary to a list and retrieved as needed. I guess it could be swapped to file as well. This appears to be the approach that the Virtual Print Engine (VPE) takes.

I am creating a class called CPrintPreview that EXTENDS CPrint (<-- that's Jose's class from his WinFBX library).

I'll keep plugging away at this and eventually post the final code when completed. It's pretty small and lightweight so far. My goal is to replace my dependence on the libharu pdf library that I am using in my application.

[James Klutho]

Good luck on your print project.  I'm looking forward to seeing your class.  I'm glad EZP was good for something.  I am currently working on an ODBC wrapper with SQLightening syntax.