Tobias Krais wrote:
Hi Carsten,
One can think that this is a bug but the current implementation
distinguishes between the same command with different arguments. We did
this because one can think of the following scenario:
.uno:Clipboard?command=copy
.uno:Clipboard?command=cut
.uno:Clipboard?command=paste
Hmm. Sounds reasonable. But there is a problem: I pass a userid as an
argument. This userid changes for thousands of users, that means I'll
NEVER be able to have an icon - that is extremely bad for me, because we
use the icon within the toolbar.
If someone wants to have different icons for the scenario you describe
above, they could implement an own protocol handler for the icon and
dispatch the needed CommandURL within - thus having all you need.
Hi Tobias,
At the moment, my toolbar shows three letters instead of a picture, only
because I want to pass the userID. Is there a different way to pass this
argument, so that I can have an icon in the toolbar?
There is currently no other way than to extend the current
implementation. A solution, which is not acceptable, would be to
register the same icon for all different commands (e.g.
.Judas:PrintTrays?userID=1000, .Judas:PrintTrays?userID=1001, ... )
Or any comments on changing the current implementation?
There is another problem with an implementation which supports your
scenario. Every command with arguments would also need to check that an
image is associated with its base command. As we already have three
layers (document, module, general) where images can reside this would
need three additional requests.
- complete command URL for document icons
- complete command URL for module icons
- complete command URL for general icons
- base command URL for document icons
- base command URL for module icons
- base command URL for general icons
I am not sure if this is acceptable as OpenOffice.org already spends
some time at startup to process all icon requests. I will check if I can
extend the image search process to also support your scenario without
degrading performance too much.
Regards,
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
