Hi Paolo, >> But nowadays, dialogs in documents can embed their images, can't they? I >> remember Noel Power having implemented this a while ago. Admittedly, the >> only thing I am sure of is that this works for form controls, but IIRC, >> he also did this for dialogs in documents ... > > I must say that I was not aware of this feature however it seems more a > workaround.
Hmm - why? If we talk about dialogs and documents, then the document itself is a good place to store images which are needed in the dialog. If you disagree here, then I still do not understand your needs. >> Even if this does not work currently - those two problems are unrelated. >> I think image controls in dialogs in documents should just have the >> possibility to access the images in the document, just like form image >> controls have. > > Why unrelated? Because the problem I originally raised has nothing to do with dialogs. I want to deploy an extension, which adds some feature, and in some place in the UI, I want to display an image for this extension. There is no dialog at all here, I need a ways to specify an image by an URL which, at runtime, can be resolved to point to a file within the deployed extension. > A dialog is a dialog and a binary resource is a binary resource, so, > what is the reason for using a special technique only for dialogs that > live into documents? > Why not having an unified solution? I fear I do not know enough about dialogs to discuss this in-depth ... In my understanding, dialogs can live in documents, or in the application-wide dialog library. Also, they can be exported from within the dialog editor as extension (can they?). Conceptually, those are completely different things, and having a common solution might be pretty complex. (Where "solution" reminds me that I am not even sure I have an understanding of the problem. I don't even think that the problem statement can be worded in a way that it applies to all three above cases.) >>> An alternative approach would be to extend the image control (and any >>> other image-aware control) with the possbility to store itself the image. >> Well, there's a place in ODF for images, I don't think that image >> controls in dialogs in documents should invent another location. As said >> above, they should simply be able to use document-embedded images. > > I respect your opinion but as i said before I find this approach not > consistent Why? If you insert an image in Write, and tell it to be not linked, then it is embedded into the document. If you insert an image form control, and tell it to not link, then the image is embedded in the document. If you put a dialog into a document, and in this dialog, have an image control, and tell it to not link its image, then the image is embedded in the document. I don't see an inconsistency here. > AWT controls and dialogs can live into documents, in shared libraries or > into extensions but the problem of the resource storage is the same. I don't think the problem is the same. Conceptually, documents, intended to be easily moved around, are different from extensions, intended to deployed into an OOo installation, and again different from the shared dialog libraries belonging to a given fixed OOo installation. In all three cases, the "non-resource" files are stored in completely different ways, so it is pretty difficult to find a common storage concept for the associated resources, /me thinks. I'd say that for shared libraries, the problem does not really exist. Those libraries are not intended to be moved around, so there's no need for some kind of embedding. For documents, I still think that embedding the images (or other resources, that is) into the document is the way to go, since the document file itself is what the user will move around. For extensions, I'd say that the .oxt format really is only a container which comes into existence when you want to deploy the extension. During development of the extension, it doesn't matter at all where the resources are located. But you actually create the .oxt file, then it needs to be ensured that it is self-contained, i.e. contains all resources, and correct references to it. And this brings us back to the "extension IDE": No matter which approach we would choose for storing and referring images and other resources, the "export as extension" functionality needs to know about it. And that's the crucial and missing point, IMO. Ciao Frank -- - Frank Schönheit, Software Engineer [email protected] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Base http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
