Properties dialog

[anovy]

Hi,
Is there a way how to call your Properties dialog for a given IPXCPrinter instance?

And another question: Why the properties do not have a 'get' method?

[Ivan - Tracker Software]

To show printer's preferences dialog you can use the Windows' API as with any other printer. Here is a sample in C++ of how to do this:

Code: Select all

BOOL ShowSettings(IPXCControlEx pPrinter, HWND hParent)
{
	HANDLE hPrinter = NULL;
	BSTR sName = NULL;
	BOOL bOK = FALSE;
	BYTE* pDevmode = NULL;
	do
	{
		HRESULT hr = pPrinter->ApplyOptions(0);
		if (FAILED(hr))
			break;
		hr = pPrinter->get_Name(&sName);
		if (FAILED(hr))
			break;
		if (!OpenPrinter(sName, &hPrinter, NULL))
			break;

		LONG nDevModeSize = DocumentProperties(NULL, hPrinter, (LPWSTR)sName, NULL, NULL, 0);
		if (nDevModeSize <= 0)
			break;
		pDevmode = (BYTE*)malloc(nDevModeSize);
		if (!pDevmode)
			break;
		if (DocumentProperties(NULL, hPrinter, (LPWSTR)sName, (DEVMODE*)pDevmode, NULL, DM_OUT_BUFFER) < 0)
			break;
		LONG nRes = DocumentProperties(hParent, hPrinter, (LPWSTR)sName, (DEVMODE*)pDevmode, (DEVMODE*)pDevmode, DM_IN_PROMPT | DM_OUT_BUFFER);
		bOK = nRes >= 0;
	} while (FALSE);
	if (pDevmode)
		free(pDevmode);
	if (sName)
		SysFreeString(sName);
	if (hPrinter)
		ClosePrinter(hPrinter);
	return bOK;
}

And another question: Why the properties do not have a 'get' method?

Because there is ResetDefault() and default values for all possible properties are documented.

[anovy]

To show printer's preferences dialog you can use the Windows' API as with any other printer.

I know and I already tried the DocumentProperties before I asked. This gives me the DEVMODE structure, which I then use in CreateDC.
But I noticed this strange thing:
If I use this technique with the static XChange printer (i.e. printer installed with XChange API setup and named "PDF-XChange 4.0") then all works OK. However if I use this technique with a temporary PDF-XChange printer (created by IPXCControlEx), then some parameters from the DEVMODE are not used (for example Watermarks, Headers, Footers etc.). It seems that the basic (documented) DEVMODE parameters (as paper size, orientation etc.) work with temporary printer, but the private parameters not.

And another question: Why the properties do not have a 'get' method?

Because there is ResetDefault() and default values for all possible properties are documented.

However I need to know what some parameters are after I will call your Properties dialog (the user can change the parameters here).

[Ivan - Tracker Software]

Watermarks, Headers, etc. are not stored in DEVMODE, so, I don't know how you want to use them.
To specify these parameters you have to use driver's API.

[anovy]

Watermarks, Headers, etc. are not stored in DEVMODE

Yes, I just noticed that.

Anyway, the question is still the same. Why these parameters defined in Properties dialog are not used, if the printer instance is temporary (i.e. created by IPXCControlEx). Then using your Properties dialog (as you described) with such instance has no sense. I want to utilize your Properties dialog, because its user interface is good and rich (mainly for watermarks and headers/footers) and it has no sense to duplicate it by my own development.

[John - Tracker Supp]

The point is - we are providing you with a developers Toolkit and not an end user product - it is therefore your responsibility to code all you need/wish to present to the end user to control/deliver output and this is not likely to change I am afraid.

[anovy]

OK, I accept this.

But then of course has not sense to suggest me how I can call your Properties dialog.

[John - Tracker Supp]

Thats the point - I am afraid you cannot call this properties dialog - you must create your own dialog and show your client this - then you pass these parameters (as are allowed) to our drivers API for PDF creation.

Your end user client cannot interact directly with our end user interface and this is intentional.

[anovy]

Yes, this is why I asked how to call your Properties dialog, I got a positive answer from Ivan (instructions, how to do this), but then all this shows as useless...

Nevertheless, there is still one question, which I asked and which I still need to clarify:
Why you do not provide "get" methods for parameters? You provide methods to save and load the parameters (StorePrinterOptions and ReStorePrinterOptions), but I don't see a sense of these methods if you do not provide "get" methods.

[John - Tracker Supp]

The get methods are not relevant - you need to set these paremeters 'fresh' with each job sent - any existing values set within the end user UI are not available for querying by a developer as it was never intended to provide such interaction - we utilise default values in the event a developer chooses not to set any values in the properties already outlined - but as far as providing end user/developer interaction via the UI - this is not catered for.

The only way for you to do so is to code your own application dialog and request user input and then pass these to the driver as allowed by the API - please remember this is a developer toolkit - not an end user product and therefore any interaction between your end user, the driver and you - must be coded by you directly and that is intentional.

[anovy]

Please forget the UI for parameters. This was already discussed and cleared.

My question was (and still is) why you provide the developers with the methods to save/load parameters and not "get" methods. I think that save/load methods have no sense without "get" methods, which I need after loading the parameters.

[John - Tracker Supp]

We provide developers with these methods to set the driver parameters on the fly to the desired output ..

I see absolutley no legitimate use that is desireable for us in terms of the allowed use of the SDK drivers under the developer licensing to provide such 'Get' methods - you and your user are licensed to use our drivers under the terms of the SDK from within your application only - which leaves all responsibility and access to the drivers to be coded by you and not in anyway provided by your end user and our products directly.

The only point in us 'inheriting' value defaults from the driver properties directly is to ensure there are some basic default values - not to provide a means to 'retrieve' and/or manipulate them - which unless I am very much mistaken is what you wish to do.

If you still believe there is some misunderstanding on my part - then please explain simply and clearly step by step what you are trying to achieve and I will be happy to respond accordingly.

[anovy]

All what I want is to utilize all possibilities of your API to save my own work. If I see that your API provides methods for save/load parameters, then I say good, I will use them and I don't need to code my own save/load methods. However then I see that you don't provide "get" methods and I'm confused. What is sense to provide load method without get methods, so I cannot know what was loaded?

BTW:
I absolutely respect your rights to provide the developers with what you want. I'm only asking if I see something, what I don't understand. For example I'm using also your XChange PDF viewer for developers, and here I don't see such restrictions. This API is available with your full UI interface and with "get" methods for all parameters.

[John - Tracker Supp]

believe me I am not trying to be unreasonabley obstructive ...

We currently have a couple of ongoing issues where developers have been using the SDK in an attempt to create a general puprose PDF creation tool independant of any vertical market application such as a DM system etc, which is a fundamental pre-condition of licensing the SDK Drivers API - and this is where our paranoia sets in as I believe you will appreciate, by far the bulk of our revenue comes from our end user products and the Developer tools are a useful but relativley secondary source of revenue.

Therefore we have to protect carefully our primary source of revenue and this is where this reuluctance to extend developer access to the potential for the end user UI to be 'tapped' in anyway.

The Viewer Ax is however a different story as that fundamentally allows a developer to embed and use the end user product and all its richness within their applications directly - coupled with the fact that we essentially offer 85% of the Viewer functionality to end users free of charge anyway.

If I may I will take a 'time out' on this for a day or so and discuss internally here and advise if we can 'relax' in this area as required thereafter.

Thanks for your patience.