Udating public devmode with IPrintOemDriverUI::DrvUpdateUISetting

[Steven Velez]

Hello,

I am working on a unidrv ui plug-in and I basically need to eliminate and
replace all default UI. With some limitations we have been able to change
the visual aspect of the UI completely by hiding all unwanted controls and
adding new ones on the property initialization messages and by adding whole
now property pages. However, now that we want to be able to store the
information that the user selects, we are running in to problems.

As an example, I have the following code:
optOrientationItem = &cacheStruct.pOEMUIParam->pDrvOptItems[3];
iIndex = SendMessage(GetDlgItem( hDlg, IDC_COMBO_DPI),CB_GETCURSEL,0,0);
optOrientationItem->Sel = iIndex;
optOrientationItem->Flags |= OPTIF_CHANGEONCE;

cacheStruct._piOEMHelp->DrvUpdateUISetting(cacheStruct.pOEMUIParam->poemuiobj,
optOrientationItem,
NULL,
OEMCUIP_DOCPROP);

In this case, OPITEM 3 is the print quality option. According to the docs,
on DrvUpdateSetting, we must call this function whenever we change OPITEMS
that correspond to the public devmode structure. It doesn't say what the
call will do for me exactly, and that is where my question is.

I am confused as to how to update the public devmode structure (as that is
what I want) because that call produces different results if I am testing in
notepad or if I am testing in excell.

In excell, everyting works as one would expect. If I change the value of
optOrientationItem->Sel and then call DrvUpdateUISetting, then once the
property sheet's OK button is selected, the public devmode structure is
updated with the proper value (I verify this by setting a data breakpoint on
the appropriate memory address.... also when loading the property sheet
again, the new values are provided). If I use the debugger to skip this call
then the new value is not merged in to the devmode.

In notepad, nothing seems to work. The results are the same wether I call
DrvUpdateUISetting or if I skip it. It seems as if the call does nothing.
One thing I can do is to allow the appropriate default control to display,
change (through the GUI) it to mark it dirty and then change the value in my
control. However, this is not really helpful in a real-world scenario.

I have also tried modifying the devmode directly and this also does not seem
to work.

I am wondering why the two applications behave differently as the
implementation for the function is in the unidrv dll and the parameters to
the function look identical in each case (the values of optitem are almost
the same in both cases... in excell, optOrientationItem->Flags has 0x80000000
set, and notepad only has this flag set if I first interact with the standard
control... I can not find a defined, documented symbol for that flag in this
context.)

What is the proper way for updating the public devmode structure from within
a unidrv ui plugin? The handler is window proc associated with a custom
property page.

--
Steven Velez
Hanna Strategies
Sr. Software Engineer

[Caz Yokoyama[MSFT]]

Have you looked at syncset sample code which you find in
..\<ddk>\src\print\oemdll?

SYNCSET: Synchronization plug-in. This sample demonstrates how to
synchronize driver settings between the OEM customization page and the
standard device settings page.

It seems you are doing the one syncset implemeted. The functions you may
look at are ChangeOpItem and OEMPrinterUICallBack.

[Erik]

I have been trying to hide the standard UI for some time now, without
any luck. I would be very grateful for any tips, or code even, for how
you achieved this.

Thank you. /Erik

[Steven Velez]

Well hello Caz,

I'll bet you are tired of hearing about my problems :) Anyways, I looked
at the sync sample and it differs in to ways.

1. The OEMPrinterUICallback and the ChangeOptItem functions are used from a
device property page. I am concerned with document property pages....
should this matter? OEMPrinterUICallback uses SetPrinterData, and while I am
not familiar with that fucntion, can I assume it affects the curren
doucment's DEVMODE?

2. The portion of the sample that implements doc prop sheets uses a CSPUI
page and modifies a private devmode not the public. So I don't think it
applies.

One difference I did see is that the device propsheet handles the PSN_APPLY
wm_Notice by calling CPSFUNC_SET_RESULT with CPSUI_OK... I tried to add this,
but that message is not being sent in my case... (no apply button) so I
don't think this is the key difference.

Other than that, I am already doing what CHangeOptItem does.

ANy more advice?

Thanks

--
Steven Velez
Hanna Strategies
Sr. Software Engineer

"Caz Yokoyama[MSFT]" wrote:

> Have you looked at syncset sample code which you find in

> ...\<ddk>\src\print\oemdll?

[Caz Yokoyama[MSFT]]

Have you looked at psuirep sample on ...\<DDK>src\print\oemdll\psuirep? It
hides standard UI and only has Options tab in printing prefernces.

[Caz Yokoyama[MSFT]]

Have you looked at GetPrinter and SetPrinter? They get and set
PRINTER_INFO_2. It has pDevMode. You can modify and set the new value back.

[Steven Velez]

I have not looked at this until you pointed me to it.

However, I don't think this will help me either... according to the docs on
PRINTER_INFO_2:

pDevMode
Pointer to a DEVMODE structure that defines default printer data such as the
paper orientation and the resolution.

This changes the default printer data. Am I mistaken in assuming that this
is not the same as modifying the pdevmode that is passed to the ui plugin? I
am particularly worried about what will happen when the print settings for a
particular document are changed while that document is in the print spooler
queue.

Thank You,
Steven

--
Steven Velez
Hanna Strategies
Sr. Software Engineer

[Caz Yokoyama[MSFT]]

Could you try using SetPrinter in your driver and find if modifying default
printer data is OK for you? I afraid if I understand your words correctly.
Once application submits a print job, it is not affected by UI operation.

[Steven Velez]

Of course I will try the suggested solution. I was already in the process of
doing that. I am trying to restructure the code quite a bit at the same time
so it will take me a little while.

However, while I am working on that, I would like to discuss the
side-effects of modifying the default settings when what I really want to do
is modify the settings for a print job.

Assuming that modifying the default settings will change the effective
settings for the job the user is about to submit, can you tell me what will
happen in the following cases?

1. Lets say we have 3 large documents to print. We print the first one
with a portrait orientation. WHile the first one is still printing, we print
the second one with landscape orientation. Also while the first one is
printing and the second has not yet begun to print, we print a third one with
portrait orientation. How will the second one print? Since we have changed
the default settings before it started to print, will it be printed portrait
or landscape?

2. The second scenario happens in the situation I described in my last post.
If I print these same three documents, go to the "printers and faxes"
folder, and "open" my printer I will see a queue with my three documents in
it. I can then right click on any of the three documents and select
properties. Here I see my documents setting UI again.... you said that once
a document is sent for printing, you can not change the properties. Does
that mean this ui has no effect? If it does, then the case in problem one
may be compounded. Not only can settings on later documents affect earlier
documents, but the reverse may also be true. I could change the settings on
a document that affect documents that come after it in the queue.

In addition I am also not sure if the user will consider it likely that
changing the settings for a document from within an application will change
the global default document settings for a printer.

I will try to report on the succes of using SetPrinter before the end of the
day.

Thanks.

--
Steven Velez
Hanna Strategies
Sr. Software Engineer

[Steven Velez]

Hi Caz,

I managed to finish trying set printer on two of the devmode properties
(dmPrintQuality and dmYResolution).... and doing this does in fact set the
values to where they are readable on subsequent opens of the property
pages... however, whe the values are set, it affects the display of the
property sheets in other applications (other pritners do not do this).
Additionally, in note pad, the proper values is not recieved by the rendering
plug-in's DrvEnablePdev implementation.

Is it possible that some applications jsut don't bother managing portions of
the DEVMODE structure?

THanks.

--
Steven Velez
Hanna Strategies
Sr. Software Engineer

[Caz Yokoyama[MSFT]]

I don't know the answer. Please open a service request if you want. Once I
receive the service request, I will investigate and answer your question.
Thank you.

[Steven Velez]

OK, but before I call.. will I need to have the ui plugin building with the
DDK's build.exe, or will Visual Studio be sufficient... please say VS is ok.
Please, please, please :)

--
Steven Velez
Hanna Strategies
Sr. Software Engineer

[Caz Yokoyama[MSFT]]

Please please please please use ddk build command.

[Steven Velez]

OK, but let me blow off some steam on this topic.

There is no reason at all why Visual Studio Projects should not be
considered for review by Microsoft's ddk support department. Especially when
the target platform . The compiler and linker that are distributed with the
latest version of the ddk are virtually identical to those provided by visual
studio. It may be argued that the ddk build tool provides certain compiler
and linker options that are necessary for certain projects, but with enough
knowledge of build.exe "sources" filess and the supported macros most if not
all of these can be overridden and changed, and the benefit of a well defined
base is lost.

I assume that the ddk build system is desireable because it can be used by
people who do not have VS licenses to build the samples. However, for those
that do, providing a few template dsp or vcproj files would be much more
effective to use on real-world projects.

The reason for this is becasue the build.exe tool is very constrictive on
what defines a project. Basically all sources for an output must be in
exactly one directory... there is no flexibility in distributing sources (yes
I can split my project in to a bunch of libs, but why should I have to do
this if the code is not reused at that level?) Also there is little to no
flexibility on where I keep my precompiled headers, and finally if my company
does day-to-day development in one environment why should I have to port my
build system just to have a technical question considered which may or may
not have a simple, superficial solution. The last time I had to do this, it
took almost 2 weeks as you well know.... and also as you know the problem was
later traced to an area not in my code... so that was 2 weeks of wasted
effort.

I could understand a little better if I was trying to tell you that I do my
development with gcc, CodeWarior, Watcom, or C++Builder, but it just seems
that VisualStudio (since it _is_ an MS product) should get a little more
support.

However, in the end I need your help more than you need my business, so I
guess I will do the port. Hopefully since this is my second time it will go
more quickly.

--
Steven Velez
Hanna Strategies
Sr. Software Engineer

[Erik]

Thanks. I had looked in the wrong places. Now it works.