PrintDlgEx routine

[Techie42]

Hi all,

I don't know if this is any use to anyone, but I wanted to use PrintDlgEx (instead of PrintDlg), and so I wrote a basic set of routines to handle some of the functionality.

A ZIP file can be downloaded from here.

The ZIP contains two files, "eezyPrinterDialogEx.pbi" and "test_it.pb". Just unZIP them both into a folder and compile/debug "test_it.pb".

There are some notes in both files, but very little in the way of error checking.

You will need a "comdlg32.lib" which contains references to "PrintDlgEx"; I believe this was made available from Windows 2000 upwards. Alternatively, you could probably modify the routines to use "comdlg32.dll". You can download the relevant copy of "comdlg32.lib" from here.

I use PB 4.10 Beta 3 under Windows XP Pro, but these routines may work under slightly earlier versions; you will need to remove the conditional compilation tests from the beginning of the files.

Please feel free to use these files and their content in any way you wish, but if something untoward happens, then please do not hold me responsible; use at your own risk.

If you have any comments, suggestions or complaints, then just let me know and I'll try to help.

Thanks.

[rsts]

thanks for sharing. I should have occasion to test/use this in the very near future.

cheers

[Tomi]

Hi sir
I need to your Printer_Lib urgently
but it don't work in PB 4.3 and next ver
my project started in 4.30 and i don't want move to other versions now.
have you a solution for this prob?
Error:

Please help me
Thanks

[Techie42]

Hi Tomi,

I just downloaded my own files from the link in this post, and managed to compile both the "eezyPrinterDialogEx.pbi" and "test_it.pb" files, without any errors, using PB 4.31 and PB 4.40 Beta 2.

I also changed the compiler settings from unicode to non-unicode, and they still compiled fine.

Unfortunately, I cannot reproduce the problem you're experiencing. Just for your information, I have the "Droopy" and "PBOSL" libraries installed (PB 4.31 only, NOT PB 4.40 Beta 2).

I did search within the PB forums and found the following issues regarding "StringExtension"...I hope this information helps.

viewtopic.php?f=7&t=36556&hilit=stringe ... 674021e2e7

viewtopic.php?f=7&t=37774&hilit=stringe ... 674021e2e7

The consensus from the above URLs seems to indicate an issue with a PB userlib...maybe an out-of-date version for the version of PB you're using. The only two suggestions I can make at this stage are:

i) update any userlibs to the latest versions for the version of PB you are using
ii) temporarily remove your userlibs or install PB into another folder without adding any userlibs to see if that makes a difference.

If none of the above information helps, then please let me know and I'll try and investigate further.

Thanks,
Techie

[Tomi]

many thanks for guides me
I try and reply here

sorry for a delay in reply, i was in travel and dont have Internet...

[Tomi]

Thanksful
Work nice in PB 4.40 Beta 2

an important question:
i use this : "Import "C:\ComDlg32.lib"" for ComDlg32.lib
in other pc, what's it?
need to import in other pc?
can i use datasectoin for make standalone file.exe?

[Techie42]

Hi Tomi,

I'm glad it's working for you. Just out of curiosity, would you mind letting me know how you resolved the issue, as it would probably be useful for others to know.

ComDlg32.LIB is the Windows "Common Dialog Box" library file. It provides definitions for accessing the standard Windows dialog boxes for choosing fonts, colours, etc..., as well as the "Print Dialog / Property Sheet" used by the PB code. Further information can be found in the MSDN documentation, or searching Google.

http://msdn.microsoft.com/en-us/library ... S.85).aspx
http://msdn.microsoft.com/en-us/library ... S.85).aspx

Information on the PB "Import" instruction can be found in the PB Help file. As the Help file states, using Import makes it easier to declare external functions. Using imported libraries has the advantage that the PB compiler helps to identify declaration problems. A disadvantage is that we assume that the "comdlg32.DLL" (which the comdlg32.LIB file lists the definitions for) will be available on all the Windows computers our compiled EXEcutable will be used on.

Alternatively, you could use the PB instructions OpenLibrary and CallFunction. The advantage of this approach is that you can detect any problems (i.e. the library may not be available on a given PC, or the particular version of the library may not contain the specific routine(s) required) and act accordingly.

Personally, I prefer to use "Import" as I tend to know the target environments that I'm coding for.

All of that said, the file "comdlg32.DLL" should already reside on target computers, and by defining the routines your software uses, by using Import or OpenLibrary, you should not need to do anything further on target PCs...but there can always be exceptions!

Btw...I've never tried to put "comdlg32.DLL" in a DataSection. My gut tells me it is not the best approach, as the file is a Windows system file. Also, including the "comdlg32.LIB" in a DataSection will make no difference, as the file only contains information as to how the routines are defined within the equivalent DLL, not the actual routines themselves. Therefore, your software would still try to use the currently installed DLL file. I wouldn't use the DataSection approach in this instance.

If you are really concerned as to the availability of a given version of comdlg32.DLL, then don't forget you can use the PB instruction "OSVersion()" to ensure the target PC is running a specific Windows version.

For example:

If (OSVersion() >= #PB_OS_Windows_2000)
.....; Only run me if I'm running on Windows 2000 or newer...
EndIf

[Tomi]

Hi Sir
You're All right, many thanks for your guides and explanations.

[Techie42]

Hi Tomi,

Thank you, and you're very welcome!