From: Steven Velez on
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
From: Caz Yokoyama[MSFT] on
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.
From: Erik on
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