Hi Subbiya;

  Unfortunately, the PowerWiz product is long time outdated / deprecated and is using very old ANSI external API's conventions (OK for old MS-Windows versions). As PB is now Unicode (as of PB version 10.x) and so are today's MS-Window versions (W10 & higher, W2016 & higher), these old API calls should be refactored to use Unicode conventions. However, these external APIs might not exist of have been refactored by Microsoft - so they may not even be supported any longer my recent MS-Window releases. Added to that, Appeon PB is now build and runs on VC++ 2022 which is a much newer "C" compiler from Microsoft - adding to the requirement to only us Unicode practices.

  The good news though is that Appeon PB has native printer commends to now allow PB Apps to control printers. Have a look at the new PrintGetPrinter, PrintGetPrinters, PrintSetPrinter and PrintSetupPrinter built-in native commands.  HTH

Regards .. Chris

Hi, Subbiya -

Are you running this app in 32-bit or 64-bit? If you are using 64-bit, can you test in 32-bit to see if it works?

The error appears to occur when the SetPrinter Windows API function is called. If I were to guess, I'd say the issue may be related to the structure that is passed by reference to this API. The value 2 that is passed as the second argument to this API function indicates that a PRINTER_INFO_2 structure is to be passed, which you did not provide in your post.

This object/code is pretty old (roughly 25 years) and passes character and string information in ANSI instead of Unicode, but someone has made changes to switch the datatype of Windows handles to Longptr.

Are you able to zip the exported source for the n_powerwhizz object and a small test app that exhibits the problem issue? If so, I can take a look and try to find the problem in my spare time.

Best regards, John

I've examined at a cursory level the Powerwhizz non-visual object (NVO) code. It appears that someone has begun to make changes to this object's code in an attempt to make it work in a 64-bit application, which makes it difficult to accurately assess the effort that would be required to successfully migrate this object for it to work in 64-bit. These recent changes have currently made the object unusable in a 32-bit environment. Information I've seen on the web leads me to believe that Powerwhizz was initially created in 1998 using PB 7. That's a long time ago and a lot has changed in PB and in Windows!

The object contains 13 internal structures, nearly all of which are used to pass information into and out of Windows API functions. All but two (the devnames and systemtime structures) would require refactoring in order for them to be used in a 64-bit Unicode application. By the way, I concur with Chris that ANSI strings and characters should no longer be used with Windows API function calls. It causes PB to have to perform unnecessary encoding translations and structure conversions and the repacking of structure member values when exchanging data between the PB app and Windows.

The object contains 29 external function declarations to interface with various Windows API's. Nearly all need to be refactored for 64-bit use, and doing so would necessitate changes to any code that calls these external functions, which would also undoubtedly require changes to the datatypes of some of the arguments to the object functions in the NVO.

Some of the structures contain a member that should be assigned the size, in memory, of an instance of that structure. Currently, those structure sizes are coded as instance variables/constants in the Powerwhizz NVO. Changing from ANSI to Unicode increases the size of any structure that contains character/string information (ANSI characters are stored in a single byte, Unicode characters required two-bytes each). If that wasn't enough, the 64-bit version of many of the structures will also increase the memory size of an instance of a structure, due to several factors which I will not go into here.

Any structure members which Windows expects to be defined in a byte or in an array of bytes are currently coded in the Powerwhizz NVO as datatype char. This works in an ANSI implementation, but these datatypes need to changed to Byte for use in a Unicode environment.

What this all boils down to is: The refactoring of the Powerwhizz object so that it will work in a 64-bit Unicode application is a substantial effort that will require the developer to have the necessary expertise. Yes, it can be accomplished, but depending on the skill and expertise of the PB developer, I estimate it would take between two to six weeks (or more) to accomplish. The required changes may then also require changes to be made to the application that is using the Powerwhizz NVO.

Finally, it is important to note that the Powerwhizz source code is clearly copyrighted, so anyone that performs the refactoring of this object may be breaking copyright law.

Best regards, John

Hi John Fauss, 
Thankyou for the reply. We are on 64bit. I have attached a small example application where i'm using powerwhizz to change the printer properties, can you please have a look on that. Thankyou.

Hi Chris,

We are already on PowerBuilder 2022 R3. We are using PrintGetPrinter(), PrintGetPrinters(), PrintSetPrinter() and PrintSetupPrinter() functions to change the printer but how can we modify other printer properties such as page size, source, orientation, Copies, etc.. Our requirement is to modify the printer settings without opening the printer setup dialogue box at runtime. Just want to have an understanding how other clients handles this situation, is there any dll/api available to change the printer properties. Can you help us to solve this problem. ?

Thankyou,
Subbiya