On 12/9/13 12:16 PM, Jörg Schmidt wrote: >> From: Andre Fischer [mailto:awf....@gmail.com] > >> Two comments: >> >> - The office is not necessarily running when an extension is >> installed. >> In that case a post-installation job can not be run. > > you're absolutely right, but please think a little more general: > > an extension developer knows that beforehand and can take into account. > > When I ask about the possibility of a script after installation to run > automatically so that is quite flexible, a partial solution would start > already there where the license dialog would be really suitable display any > information. > > Yes, I can, instead of the license, display any text, but not formatted. Much > would be won if one could show there html texts (including links)
the idea of having pre and post install hooks is not new and not a bad one. It's just that it have to implemented and it puts a further complexity in the already existing extension framework with too many specialties. I would first think about a redesign to remove the complexity (which is not necessary at all) and then add new features like this. But based on a well designed and defined workflow. > >> - Something similar to what you propose may already be >> possible. I am >> not sure about the details, but I think that you can specify >> jobs to be >> run on certain events (application start, document creation, >> etc). It >> may be possible to specify a job to be run exactly once. >> See >> https://wiki.openoffice.org/wiki/Documentation/DevGuide/Writin >> gUNO/Jobs/Jobs >> for details. > > yes, right, I know. > > However, I have not yet properly understood (OK, my mistake) and > unfortunately have to note that the uses hardly anyone what my suspicions > intensified, which is not particularly well used. > > OK, I'll only use your suggestion and concern myself with it again in more > detail. > > > quite openly: > it is a latent weakness of OpenOffice (and LO) is insufficient to address the > needs of macro programmers. > e.g. in MS Office VBA contributes to this success. "VBA" here is not the > language alone, but much more need what macro programmer, eg a good IDE and > much more. > it is a known issue and it is hard to provide a similar framework. It's always the same you need volunteers who are interested to work on this. Plug or use existing IDE's like Eclipse or NetBeans to do more enhanced macro programming and provide a much better tooling is of course an interesting challenge and possible. We had started to use for example NetBeans a long time ago for Java macro programming. But it was never finished or left the prototype status. It's easy to say what's missing comparing to MSO but more difficult to deliver something useful. Juergen --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
