4

I've been bitten by this old bug/missing feature in Java:

http://bugs.sun.com/view_bug.do;jsessionid=b2ac8ea11f05c16d948e24d36fb5?bug_id=4673406

The thing is that the "Properties" button in Java's standard print dialog is seemingly always disabled on Windows. The button is only enabled if PrintService.getServiceUIFactory() returns something that isn't null. Unfortunately Win32PrintService instances always return null. Always.

By googling, I discovered that you can invoke Windows' own print properties dialog thingy by calling rundll32:

rundll32 printui.dll,PrintUIEntry /e /n "name of printer here"

I'm hoping I can use this to circumvent the bug/missing feature in Win32PrintService. However, I don't know how I can query the PrintUIEntry-dialog for the user's choices.

In other words, how can I get a result of the above rundll32-invocation? (If I have to write something in C/JNI and use the Windows API directly, so be it. I'd rather not, though.)

Or is there a better way to solve this problem?

perp
  • 3,883
  • 4
  • 31
  • 29

1 Answers1

5

rundll32 does not give you any return value, its exit code is always zero.

I think you'll have to find another way.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • I did not expect it to. But there surely must be some kind of mechanism for knowing what was done in the dialog? As in, OK or Cancel, and if OK, what properties were set and what were their values? Just being able to display the dialog with no access to a result, is completely useless... – perp Feb 22 '11 at 12:42
  • 1
    @perp Doesn't the system remember the settings? In other words, you let the user set them in the dialog and then when you start printing from your app, those settings are in force. – David Heffernan Feb 22 '11 at 12:47
  • That's a good question! I did not expect it to work that way, but maybe it does? I'll try it. – perp Feb 22 '11 at 12:55
  • @perp My app prints, it's not a Java app, and all I ever do is show a printer preferences dialog. I don't have anything in my app that refers to those printer preferences/settings. Admittedly, I'm using native code and a common dialog printer preferences, but I'd expect your scenario to work the same way. – David Heffernan Feb 22 '11 at 12:57
  • 1
    It sure did. My development style is so geared towards not really doing any work in dialogs, but rather return a result from them and do the actual work elsewhere. So I kind of just assumed that this dialog would return something, and not mutate Windows' settings on its own. In this case I'm happy that it does, however, it made the whole thing quite painless. My solution is a hack, but it seems to work... fingers crossed. :-) – perp Feb 22 '11 at 14:51
  • 1
    @perp printer driver, printer settings, in Windows, it's a whole world of weirdness. Mutating system state, yuck!! Anyway, glad you are in business. – David Heffernan Feb 22 '11 at 14:52
  • `Rundll32` exit code isn't always zero. If the invoked function calls [`exit(n)`](https://en.cppreference.com/w/c/program/exit), `rundll32` exit code would be `n`. (The other thing is that a _result_ of the invoked function isn't considered, i.e. `return n` wouldn't automatically set exit code, but still there're ways to set it.) – Sasha Nov 01 '19 at 07:43