Re: [discuss] Poor choice of macro language (Object Model)
Hi, Mathias Bauer schrieb: As an example for the second approach, we have some objects that offer an API like: n = MyObject.getPropertyValue( PropName ) Basic can automatically inspect this object and allows you to write n = MyObject.PropName Do we have an overview which simplifications are provided by OOBasic? Things that I currently know are: obj.Property = value instead of obj.setPropertyValue( Property, value ) value = obj.Property instead of value = obj.getPropertyValue( Property ) obj.Function = value instead of obj.setFunction( value ) value = obj.Function instead of value = obj.getFunction() obj( i ) = value instead of obj.setByIndex( i, value ) value = obj( i ) instead of value = obj.getByIndex( i ) and even value = obj.Function( i ) instead of value = obj.getFunction().getByIndex( i ) :-) Regards Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Poor choice of macro language (Object Model)
Ian Laurenson wrote: oSearchDescriptor = thisComponent.createSearchDescriptor oSearchDescriptor.setSearchString(the) oFirstSelection = _ thisComponent.getcurrentController.getSelection.getByIndex(0) oFound = thisComponent.findNext(oFirstSelection, oSearchDescriptor) As FindNext is only a method of the Writer component and not of a text range, if the search string is not in the selection the code continues searching until either the end of the document or the string is found, where upon you need to check if it is inside the range with something like: bFound = (thisComponent.getText.compareRegionEnds(oFound, _ oFirstSelection.getEnd) -1) But this is an over simplification as the text ranges may not belong to the same text range (e.g. in Table), and the end of a text range is determined by the direction of the selection. For a more complete and working example see: IannzFindReplace.sxw available from: http://homepages.paradise.net.nz/hillview/OOo/ Thanks, I will have a look. I'm always interested in spotting weaknesses of our API. If they turn out to be either *very* annoying or if they concern often used functions we will think about additional solutions. * Having an enumeration for PageLayout that doesn't include an option for none when you simply aren't concerned about duplex printing. Sorry, I don't understand this. Can you show it with a few code lines? I was referring to: http://www.openoffice.org/issues/show_bug.cgi?id=3910 Thanks, I will also study this. A much higher priority for me is having more in the API such as the ability to easily have docked/floating windows in extensions. This is a feature we have considered for the next release. The biggest obstacle is that we lack a proper GUI toolkit, but at least we should be able to offer all controls you can use in a basic dialog also for docking/floating windows. As an example, we could use the xml description of a Basic dialog and declare it as a floater or a docking window. Docked/floating windows is quite an important issue for me. Is there anyway that I can create a component with this functionality now? No, this is not possible with components, means: objects created outside the main code base like an Add-On or so. Currently you need to create objects based on classes from our SFX library and you need to adapt the code of an application to use that object. This is usually nothing you want to do as an external developer because even if you took the entrance hurdle you would need to maintain the code in case of future changes of our code base. Should I look into helping to change the source code for this issue (this would be my first attempt at writing OOo source code - so I may need some help)? The necessary code changes are not trivial: we must implement a new splitting window class in VCL, new docking handlers in the Framework Layout Manager and a new base class that implements the basic handling (the current base class in in SFX2). We also must adapt the code of all current dockable windows to use the new base class. To make this new implementation usable for external components we must provide new APIs and registration means and define and implement how you can specify the content of your window, e.g. by utilizing the Basic dialog XML files. The easiest way to help us would be to join the discussion about the new APIs and the XML resource stuff and later on help with creating prototypes and test cases. Of course brave developers can also join us in the development phase when we dig up the VCL, SFX2 and framework modules. If you want to join us in one of these steps I can notify you when we start the specification phase, further discussions then will appear on the dev@framework.openoffice.org mailing list. My gut feeling is that this will be one of the first things we will attack after the OOo2.0 release, so possibly we will start in the late summer this year. Should I just be patient and wait? Of course that's always an option. :-) Ciao, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Poor choice of macro language (Object Model)
Ian Laurenson wrote: On Wed, 2005-06-01 at 10:06, Mathias Bauer wrote: Ian Laurenson wrote: * In Writer searching is at a document level thus coding for searching within a selection is extremely tedious and the resulting code is slow. Interesting, can you provide an example that shows the problem? oSearchDescriptor = thisComponent.createSearchDescriptor oSearchDescriptor.setSearchString(the) oFirstSelection = _ thisComponent.getcurrentController.getSelection.getByIndex(0) oFound = thisComponent.findNext(oFirstSelection, oSearchDescriptor) As FindNext is only a method of the Writer component and not of a text range, if the search string is not in the selection the code continues searching until either the end of the document or the string is found, where upon you need to check if it is inside the range with something like: i agree that sometimes the generic interfaces are not enough (here XSearchable, where the first parameter of findNext only specifies the start point). I can only say please communicate the weakness of API's and/or submit RFE's so that we can try to improve it. I know that we have such weakness in a lot of areas of the API. But i also know that it is not easy to improve it that it would be sufficient for all use cases. Especially missing documentation (e.g. properties, interfaces) are bad and can be fixed simply. Juergen bFound = (thisComponent.getText.compareRegionEnds(oFound, _ oFirstSelection.getEnd) -1) But this is an over simplification as the text ranges may not belong to the same text range (e.g. in Table), and the end of a text range is determined by the direction of the selection. For a more complete and working example see: IannzFindReplace.sxw available from: http://homepages.paradise.net.nz/hillview/OOo/ * Having an enumeration for PageLayout that doesn't include an option for none when you simply aren't concerned about duplex printing. Sorry, I don't understand this. Can you show it with a few code lines? I was referring to: http://www.openoffice.org/issues/show_bug.cgi?id=3910 This issue is about the difficultly to avoid having a blank page automatically inserted to make sure that odd numbered pages are always right facing pages. All of the enumerations for com.sun.star.style.PageStyleLayout are about left and right facing pages, there is no way of specifying that left and right facing pages are to be ignored, which is relevant for simplex printing or as a desirable option for electronic printing. A much higher priority for me is having more in the API such as the ability to easily have docked/floating windows in extensions. This is a feature we have considered for the next release. The biggest obstacle is that we lack a proper GUI toolkit, but at least we should be able to offer all controls you can use in a basic dialog also for docking/floating windows. As an example, we could use the xml description of a Basic dialog and declare it as a floater or a docking window. Docked/floating windows is quite an important issue for me. Is there anyway that I can create a component with this functionality now? or Should I look into helping to change the source code for this issue (this would be my first attempt at writing OOo source code - so I may need some help)? or Should I just be patient and wait? Thanks, Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Poor choice of macro language (Object Model)
Daniel Rentz wrote: Hi, Mathias Bauer schrieb: As an example for the second approach, we have some objects that offer an API like: n = MyObject.getPropertyValue( PropName ) Basic can automatically inspect this object and allows you to write n = MyObject.PropName Do we have an overview which simplifications are provided by OOBasic? Sure we have. But I assume you wanted to ask if this information is available in public. :-) I'm not sure, I have to find out. Ciao, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Poor choice of macro language (Object Model)
Hi, Mathias Bauer schrieb: Daniel Rentz wrote: Do we have an overview which simplifications are provided by OOBasic? Sure we have. But I assume you wanted to ask if this information is available in public. :-) Right :-) I'm not sure, I have to find out. Thanks. Regards Daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Poor choice of macro language (Object Model)
On Thu, 2005-06-02 at 21:20, Mathias Bauer wrote: [snipped comments about Searching in Writer and PageLayout enumeration] Thanks Mathias for offering to look into these areas. A much higher priority for me is having more in the API such as the ability to easily have docked/floating windows in extensions. This is a feature we have considered for the next release. The biggest obstacle is that we lack a proper GUI toolkit, but at least we should be able to offer all controls you can use in a basic dialog also for docking/floating windows. As an example, we could use the xml description of a Basic dialog and declare it as a floater or a docking window. Docked/floating windows is quite an important issue for me. Is there anyway that I can create a component with this functionality now? No, this is not possible with components, means: objects created outside the main code base like an Add-On or so. Currently you need to create objects based on classes from our SFX library and you need to adapt the code of an application to use that object. This is usually nothing you want to do as an external developer because even if you took the entrance hurdle you would need to maintain the code in case of future changes of our code base. Thanks for this information - it makes the situation very clear. Should I look into helping to change the source code for this issue (this would be my first attempt at writing OOo source code - so I may need some help)? The necessary code changes are not trivial: we must implement a new splitting window class in VCL, new docking handlers in the Framework Layout Manager and a new base class that implements the basic handling (the current base class in in SFX2). We also must adapt the code of all current dockable windows to use the new base class. To make this new implementation usable for external components we must provide new APIs and registration means and define and implement how you can specify the content of your window, e.g. by utilizing the Basic dialog XML files. The easiest way to help us would be to join the discussion about the new APIs and the XML resource stuff and later on help with creating prototypes and test cases. Of course brave developers can also join us in the development phase when we dig up the VCL, SFX2 and framework modules. If you want to join us in one of these steps I can notify you when we start the specification phase, further discussions then will appear on the dev@framework.openoffice.org mailing list. My gut feeling is that this will be one of the first things we will attack after the OOo2.0 release, so possibly we will start in the late summer this year. I'd appreciate being notified when you start the specification phase, and will try to be as useful as possible. I have joined the dev@framework.openoffice.org mailing list. Should I just be patient and wait? Of course that's always an option. :-) Thanks, Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Poor choice of macro language (Object Model)
Sander Vesik wrote: --- Mathias Bauer [EMAIL PROTECTED] wrote: Currently we are investigating both ways: we are looking for new, simpler APIs and we are thinking about more smart capabilities of OOoBasic. It has bee a while since I have said this (mostly due to mailing list inactivity) but - hopefully something DOM-syle that is familiar with anybody who has done javascript based dynamic web pages or similar will be one such available API. No, this something completely different, I was talking about easier to use APIs, not about more complicated things. :-) Please note that we are talking about supporting macro beginners, not people that can code in JavaScript. BTW: OOo2.0 has a DOM API already, but I don't know if that's what you are talking about. The APIs I was talking about should be things that just help writing fewer lines of code to achieve the same result. BTW: your mail client (obviously Web Mail) sucks a little bit because it doesn't set a proper In-Reply-To header. Any hope you can use a better one? Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Poor choice of macro language (Object Model)
On Wed, 2005-06-01 at 10:06, Mathias Bauer wrote: Ian Laurenson wrote: * In Writer searching is at a document level thus coding for searching within a selection is extremely tedious and the resulting code is slow. Interesting, can you provide an example that shows the problem? oSearchDescriptor = thisComponent.createSearchDescriptor oSearchDescriptor.setSearchString(the) oFirstSelection = _ thisComponent.getcurrentController.getSelection.getByIndex(0) oFound = thisComponent.findNext(oFirstSelection, oSearchDescriptor) As FindNext is only a method of the Writer component and not of a text range, if the search string is not in the selection the code continues searching until either the end of the document or the string is found, where upon you need to check if it is inside the range with something like: bFound = (thisComponent.getText.compareRegionEnds(oFound, _ oFirstSelection.getEnd) -1) But this is an over simplification as the text ranges may not belong to the same text range (e.g. in Table), and the end of a text range is determined by the direction of the selection. For a more complete and working example see: IannzFindReplace.sxw available from: http://homepages.paradise.net.nz/hillview/OOo/ * Having an enumeration for PageLayout that doesn't include an option for none when you simply aren't concerned about duplex printing. Sorry, I don't understand this. Can you show it with a few code lines? I was referring to: http://www.openoffice.org/issues/show_bug.cgi?id=3910 This issue is about the difficultly to avoid having a blank page automatically inserted to make sure that odd numbered pages are always right facing pages. All of the enumerations for com.sun.star.style.PageStyleLayout are about left and right facing pages, there is no way of specifying that left and right facing pages are to be ignored, which is relevant for simplex printing or as a desirable option for electronic printing. A much higher priority for me is having more in the API such as the ability to easily have docked/floating windows in extensions. This is a feature we have considered for the next release. The biggest obstacle is that we lack a proper GUI toolkit, but at least we should be able to offer all controls you can use in a basic dialog also for docking/floating windows. As an example, we could use the xml description of a Basic dialog and declare it as a floater or a docking window. Docked/floating windows is quite an important issue for me. Is there anyway that I can create a component with this functionality now? or Should I look into helping to change the source code for this issue (this would be my first attempt at writing OOo source code - so I may need some help)? or Should I just be patient and wait? Thanks, Ian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Poor choice of macro language (Object Model)
Chris Benatar wrote: Yes, I do agree with you on this although I do feel that the object model is the way most people would see the language ie. although it is an extension of it, it is a pretty critical one. Not sure what would be involved in changing the languages interface to the object model or even if it can be done but it certainly would be welcomed. We can define new API functions and implement them so that the OOoBasic API built upon them becomes easier to use or we can add some smart functions to OOoBasic that lets it emulate easy access using the more complex API functions. As an example for the second approach, we have some objects that offer an API like: n = MyObject.getPropertyValue( PropName ) Basic can automatically inspect this object and allows you to write n = MyObject.PropName There are a lot more things possible. VBA uses the same tricks, the raw API of Word or Excel is also much more complicated than you could guess from seeing VBA code. Currently we are investigating both ways: we are looking for new, simpler APIs and we are thinking about more smart capabilities of OOoBasic. In defence of the OOo API: I can do things that were virtually impossible with Microsoft Office (MSO). For example, my reveal codes macro simply wouldn't be possible in MSO. But intruth for 99.9% of users this level of power and sophistication is not required and it comes at a price. I agree that there is a trade-off, but I disagree with the 99.9% number, I can't accept it even for the absolute beginner. Trade-offs create dynamic processes, a permanent struggle where evolving experience might allow you to approach the optimum over time. Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Poor choice of macro language (Object Model)
Ian Laurenson wrote: * In Writer searching is at a document level thus coding for searching within a selection is extremely tedious and the resulting code is slow. Interesting, can you provide an example that shows the problem? * Having an enumeration for PageLayout that doesn't include an option for none when you simply aren't concerned about duplex printing. Sorry, I don't understand this. Can you show it with a few code lines? A much higher priority for me is having more in the API such as the ability to easily have docked/floating windows in extensions. This is a feature we have considered for the next release. The biggest obstacle is that we lack a proper GUI toolkit, but at least we should be able to offer all controls you can use in a basic dialog also for docking/floating windows. As an example, we could use the xml description of a Basic dialog and declare it as a floater or a docking window. Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] Poor choice of macro language (Object Model)
--- Mathias Bauer [EMAIL PROTECTED] wrote: Currently we are investigating both ways: we are looking for new, simpler APIs and we are thinking about more smart capabilities of OOoBasic. It has bee a while since I have said this (mostly due to mailing list inactivity) but - hopefully something DOM-syle that is familiar with anybody who has done javascript based dynamic web pages or similar will be one such available API. Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. Sander .sigless ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
