Re: Vendors Name via UNO API / Basic Macros
On 26/11/2013 17:42, Lionel Elie Mamane wrote: On Tue, Nov 26, 2013 at 02:36:41PM +0100, Fernand Vanrie wrote: On 26/11/2013 13:56, Lionel Elie Mamane wrote: On Thu, Nov 21, 2013 at 08:34:04PM +0100, Jan Holesovsky wrote: Thomas Krumbein píše v Pá 15. 11. 2013 v 15:43 +0100: Well, this change was a small technical thing - but with a very big influence on typical market applications. Every custom macro application with dialogs or forms for user interfaces is influenced if dialogs/forms using Date/time fields. Have you filed a bugreport, please? A minimal example of the macro that fails would be most appreciated. Well - it´s not a bug, because you mentioned the change in release-notes of version 4.1. There are many ways how to make the problem less annoying in Basic ;-) - we control the Basic implementation, so can work around many things, and if we are lucky, this will be one of them. I am sure we'd try to do that before the release with the incompatible change if we knew early. Well, I considered doing some magic that when the property is written, why not a extra property , date = isodate as it was (all old code can run it) cdate = new way That's essentially a variant of roll back the change. 1) This requires an incompatible change again; 4.2 would be incompatible with 4.1. is suppose that there is not a lot off API-basic code around for 4.2 :-) 2) Applied to Time, it leaves the problem of round-tripping. 3) If we set DataFieldProperty to the name of the new (pseudo?)property (UnoDate? DateAsUNO? StructDate?), the other problems I'm thinking about should go OK, except that indirect access through DataFieldProperty will still be incompatible, but that should be minor? Go for it, then we can go for 4.1. If not: then please let it know, we can start changing the code using a conversion Greetz Fernand ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
On 11/26/2013 01:56 PM, Lionel Elie Mamane wrote: On Thu, Nov 21, 2013 at 08:34:04PM +0100, Jan Holesovsky wrote: Thomas Krumbein píše v Pá 15. 11. 2013 v 15:43 +0100: Well, this change was a small technical thing - but with a very big influence on typical market applications. Every custom macro application with dialogs or forms for user interfaces is influenced if dialogs/forms using Date/time fields. Have you filed a bugreport, please? A minimal example of the macro that fails would be most appreciated. Well - it´s not a bug, because you mentioned the change in release-notes of version 4.1. There are many ways how to make the problem less annoying in Basic ;-) - we control the Basic implementation, so can work around many things, and if we are lucky, this will be one of them. I am sure we'd try to do that before the release with the incompatible change if we knew early. Well, I considered doing some magic that when the property is written, if it gets an integer, interpret it the old way and if it gets a UNO Date struct, interpret it the obvious (new) way. Someone (Stephan Bergmann?) told me that one could do that for attributes but not (pseudo?)properties (or something like that); the Basic implementation (bridge?) would refuse to even pass a value of the wrong type to the C++ code. I don't see how to achieve it short of special-casing this into the bridge / other parts of the Basic implementation. Which sounds like a guaranteed subscription for maintenance nightmares, and thus not the best of ideas. Would the Basic implementation / UNO bridge people be willing to actually have that kind of special-casing? Not sure what you mean with the sentence about attributes and properties. But the Basic implementation would indeed be the place where to handle such special cases to improve backwards compatibility. (Which matches the observation that Basic authors and Basic code, which often comes included in documents, probably have the hardest time copying with our deliberate incompatibilities.) Stephan ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
On Thu, 2013-11-21 at 17:06 +0100, Lionel Elie Mamane wrote: As a matter of example, here is how to detect the alluded to change. 't would be nice if someone posted it on some documentation / FAQ / code snippets website. I added your nice fragment to the 4.1 release notes in the wiki - in lieu of some better place - people seem to read/notice that there. Thanks ! Michael. -- michael.me...@collabora.com , Pseudo Engineer, itinerant idiot ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
On Thu, Nov 21, 2013 at 08:34:04PM +0100, Jan Holesovsky wrote: Thomas Krumbein píše v Pá 15. 11. 2013 v 15:43 +0100: Well, this change was a small technical thing - but with a very big influence on typical market applications. Every custom macro application with dialogs or forms for user interfaces is influenced if dialogs/forms using Date/time fields. Have you filed a bugreport, please? A minimal example of the macro that fails would be most appreciated. Well - it´s not a bug, because you mentioned the change in release-notes of version 4.1. There are many ways how to make the problem less annoying in Basic ;-) - we control the Basic implementation, so can work around many things, and if we are lucky, this will be one of them. I am sure we'd try to do that before the release with the incompatible change if we knew early. Well, I considered doing some magic that when the property is written, if it gets an integer, interpret it the old way and if it gets a UNO Date struct, interpret it the obvious (new) way. Someone (Stephan Bergmann?) told me that one could do that for attributes but not (pseudo?)properties (or something like that); the Basic implementation (bridge?) would refuse to even pass a value of the wrong type to the C++ code. I don't see how to achieve it short of special-casing this into the bridge / other parts of the Basic implementation. Which sounds like a guaranteed subscription for maintenance nightmares, and thus not the best of ideas. Would the Basic implementation / UNO bridge people be willing to actually have that kind of special-casing? What´s happend, you can read my article on my homepage. It is in german language but I am sure, you get the context ;) http://www.mic-consulting.de/index.php/opersource/api-makros-libo-aoo/10-datumsfelder-geaendert-in-lo-4-1-1 I am sorry, cannot get the context :-( Can you please turn it into a minimal example of what used to work, and send it here? Or even better, file the bugreport, and send here the link? Another user already did that: https://bugs.freedesktop.org/68751 It already led to concrete mitigation steps (in the form of utility functions to convert between the Basic native date type and UNO Date, Time and DateTime) in 4.1.3 (correctly documented in 4.1.4). If anybody has concrete actionable ideas on how to sweeten the bitter pill (short of rollback the change), we sure can consider it. -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
On 26/11/2013 13:56, Lionel Elie Mamane wrote: On Thu, Nov 21, 2013 at 08:34:04PM +0100, Jan Holesovsky wrote: Thomas Krumbein píše v Pá 15. 11. 2013 v 15:43 +0100: Well, this change was a small technical thing - but with a very big influence on typical market applications. Every custom macro application with dialogs or forms for user interfaces is influenced if dialogs/forms using Date/time fields. Have you filed a bugreport, please? A minimal example of the macro that fails would be most appreciated. Well - it´s not a bug, because you mentioned the change in release-notes of version 4.1. There are many ways how to make the problem less annoying in Basic ;-) - we control the Basic implementation, so can work around many things, and if we are lucky, this will be one of them. I am sure we'd try to do that before the release with the incompatible change if we knew early. Well, I considered doing some magic that when the property is written, if it gets an integer, interpret it the old way and if it gets a UNO Date struct, interpret it the obvious (new) way. Someone (Stephan Bergmann?) told me that one could do that for attributes but not (pseudo?)properties (or something like that); the Basic implementation (bridge?) would refuse to even pass a value of the wrong type to the C++ code. I don't see how to achieve it short of special-casing this into the bridge / other parts of the Basic implementation. Which sounds like a guaranteed subscription for maintenance nightmares, and thus not the best of ideas. Would the Basic implementation / UNO bridge people be willing to actually have that kind of special-casing? What´s happend, you can read my article on my homepage. It is in german language but I am sure, you get the context ;) http://www.mic-consulting.de/index.php/opersource/api-makros-libo-aoo/10-datumsfelder-geaendert-in-lo-4-1-1 I am sorry, cannot get the context :-( Can you please turn it into a minimal example of what used to work, and send it here? Or even better, file the bugreport, and send here the link? Another user already did that: https://bugs.freedesktop.org/68751 It already led to concrete mitigation steps (in the form of utility functions to convert between the Basic native date type and UNO Date, Time and DateTime) in 4.1.3 (correctly documented in 4.1.4). If anybody has concrete actionable ideas on how to sweeten the bitter pill (short of rollback the change), we sure can consider it. why not a extra property , date = isodate as it was (all old code can run it) cdate = new way Greetz Fernand ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
Hi Thomas, Thomas Krumbein píše v Pá 15. 11. 2013 v 15:43 +0100: Well, this change was a small technical thing - but with a very big influence on typical market applications. Every custom macro application with dialogs or forms for user interfaces is influenced if dialogs/forms using Date/time fields. Have you filed a bugreport, please? A minimal example of the macro that fails would be most appreciated. Well - it´s not a bug, because you mentioned the change in release-notes of version 4.1. There are many ways how to make the problem less annoying in Basic ;-) - we control the Basic implementation, so can work around many things, and if we are lucky, this will be one of them. I am sure we'd try to do that before the release with the incompatible change if we knew early. What´s happend, you can read my article on my homepage. It is in german language but I am sure, you get the context ;) http://www.mic-consulting.de/index.php/opersource/api-makros-libo-aoo/10-datumsfelder-geaendert-in-lo-4-1-1 I am sorry, cannot get the context :-( Can you please turn it into a minimal example of what used to work, and send it here? Or even better, file the bugreport, and send here the link? Thank you a lot, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
On Mon, Nov 18, 2013 at 10:47:57PM +0100, Cor Nouws wrote: Thomas Krumbein wrote (14-11-13 09:21) Because in LO 4.1 we have some API-changes, macros should now have a version-switch. There are different methods to get the internal version-number - that is not a problem. But: The version number itself is not suffcient because AOO 4.1.0 will start soon and this version-number is identical to LO 4.1.0. I've not yet been looking into details to possibly distinct between pré and after 4.1.0 for the Date . https://bugs.freedesktop.org/show_bug.cgi?id=70947#c5 As a matter of example, here is how to detect the alluded to change. 't would be nice if someone posted it on some documentation / FAQ / code snippets website. Dim OOoReflection As Object Set OOoReflection = CreateUnoService(com.sun.star.reflection.CoreReflection) Dim gD as Object Set gD = OOoReflection.forName(com.sun.star.awt.XDateField).getMethod(getDate).ReturnType if gD.TypeClass = com.sun.star.uno.TypeClass.LONG then gbDateIsStruct = false elseif gD.TypeClass = com.sun.star.uno.TypeClass.STRUCT And gD.Name = com.sun.star.util.Date then gbDateIsStruct = true else MsgBox Unknown situation end if -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
On 18/11/2013 22:21, Lionel Elie Mamane wrote: On Mon, Nov 18, 2013 at 09:10:34PM +0100, David Ostrovsky wrote: Lionel Elie Mamane wrote on Mon Nov 18 09:32:57 PST 2013 On Mon, Nov 18, 2013 at 06:10:34PM +0100, Fernand Vanrie wrote: yep conversions are not the problem, its the exiting code who is broken in many places ? What exiting code? This Basic-Macros excerpt: oDlg.getControl(myDateField).date = CDatetoIso(now()) was broken in LibreOffice 4.1.1. The only known migration path is to adjust all broken places with: REM broken oDlg.getControl(myDateField).date = CDatetoIso(now()) dim oDat as new com.sun.star.util.Date with oDat .day = Day(now) .month = Month(now) .year = Year(now) end with oDlg.getControl(myDateField).date = oDat Now, if you have thousands LoC of Basic Macros, ... I had understood exiting code as the return value of a procedure, so I was completely lost as to what was meant. I now understand that Fernand meant exiSting code, where code is not a value (a number / string), but a piece of program. On a sidenote, oDlg.getControl(myDateField).date = CDatetoIso(now()) can be replaced by oDlg.getControl(myDateField).date = CDateToUnoDate(now()) Lionel, Do you mean dat going back to dlg.getControl(myDateField).date as Isovalue and adding a dlg.getControl(myDateField).cdate is not option anymore ? ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
On 18/11/2013 18:32, Lionel Elie Mamane wrote: On Mon, Nov 18, 2013 at 06:10:34PM +0100, Fernand Vanrie wrote: On 18/11/2013 18:02, Lionel Elie Mamane wrote: On Fri, Nov 15, 2013 at 03:43:10PM +0100, Thomas Krumbein wrote: Am 15.11.2013 15:35, schrieb Jan Holesovsky: Thomas Krumbein pÃÅ¡e v Pá 15. 11. 2013 v 13:43 +0100: Well, this change was a small technical thing - but with a very big influence on typical market applications. Every custom macro application with dialogs or forms for user interfaces is influenced if dialogs/forms using Date/time fields. Have you filed a bugreport, please? A minimal example of the macro that fails would be most appreciated. Well - it´s not a bug, because you mentioned the change in release-notes of version 4.1. What´s happend, you can read my article on my homepage. It is in german language but I am sure, you get the context ;) http://www.mic-consulting.de/index.php/opersource/api-makros-libo-aoo/10-datumsfelder-geaendert-in-lo-4-1-1 I took a look; since ... 4.1.2? 4.1.3? not sure anymore, you can also use: CDateFromUnoDate to replace CDateFromIso yep conversions are not the problem, its the exiting code who is broken in many places ? What exiting code? sorry: existing code like in my private macro's and some extentions who uses the date property comming from a date control ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
On Fri, Nov 15, 2013 at 03:43:10PM +0100, Thomas Krumbein wrote: Am 15.11.2013 15:35, schrieb Jan Holesovsky: Thomas Krumbein píše v Pá 15. 11. 2013 v 13:43 +0100: Well, this change was a small technical thing - but with a very big influence on typical market applications. Every custom macro application with dialogs or forms for user interfaces is influenced if dialogs/forms using Date/time fields. Have you filed a bugreport, please? A minimal example of the macro that fails would be most appreciated. Well - it´s not a bug, because you mentioned the change in release-notes of version 4.1. What´s happend, you can read my article on my homepage. It is in german language but I am sure, you get the context ;) http://www.mic-consulting.de/index.php/opersource/api-makros-libo-aoo/10-datumsfelder-geaendert-in-lo-4-1-1 I took a look; since ... 4.1.2? 4.1.3? not sure anymore, you can also use: CDateFromUnoDate CDateFromUnoTime CDateFromUnoDateTime CDateToUnoDate CDateToUnoTime CDateToUnoDateTime to replace CDateFromIso CDateToIso -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
On 18/11/2013 18:02, Lionel Elie Mamane wrote: On Fri, Nov 15, 2013 at 03:43:10PM +0100, Thomas Krumbein wrote: Am 15.11.2013 15:35, schrieb Jan Holesovsky: Thomas Krumbein píše v Pá 15. 11. 2013 v 13:43 +0100: Well, this change was a small technical thing - but with a very big influence on typical market applications. Every custom macro application with dialogs or forms for user interfaces is influenced if dialogs/forms using Date/time fields. Have you filed a bugreport, please? A minimal example of the macro that fails would be most appreciated. Well - it´s not a bug, because you mentioned the change in release-notes of version 4.1. What´s happend, you can read my article on my homepage. It is in german language but I am sure, you get the context ;) http://www.mic-consulting.de/index.php/opersource/api-makros-libo-aoo/10-datumsfelder-geaendert-in-lo-4-1-1 I took a look; since ... 4.1.2? 4.1.3? not sure anymore, you can also use: CDateFromUnoDate CDateFromUnoTime CDateFromUnoDateTime CDateToUnoDate CDateToUnoTime CDateToUnoDateTime to replace CDateFromIso CDateToIso Lionel, yep conversions are not the problem, its the exiting code who is broken in many places ? can you restore the Date property as a ISO value and add a extra property Cdate then no code is broken ? Greetz Fernand ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
On Mon, Nov 18, 2013 at 06:10:34PM +0100, Fernand Vanrie wrote: On 18/11/2013 18:02, Lionel Elie Mamane wrote: On Fri, Nov 15, 2013 at 03:43:10PM +0100, Thomas Krumbein wrote: Am 15.11.2013 15:35, schrieb Jan Holesovsky: Thomas Krumbein píše v Pá 15. 11. 2013 v 13:43 +0100: Well, this change was a small technical thing - but with a very big influence on typical market applications. Every custom macro application with dialogs or forms for user interfaces is influenced if dialogs/forms using Date/time fields. Have you filed a bugreport, please? A minimal example of the macro that fails would be most appreciated. Well - it´s not a bug, because you mentioned the change in release-notes of version 4.1. What´s happend, you can read my article on my homepage. It is in german language but I am sure, you get the context ;) http://www.mic-consulting.de/index.php/opersource/api-makros-libo-aoo/10-datumsfelder-geaendert-in-lo-4-1-1 I took a look; since ... 4.1.2? 4.1.3? not sure anymore, you can also use: CDateFromUnoDate to replace CDateFromIso yep conversions are not the problem, its the exiting code who is broken in many places ? What exiting code? -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
Lionel Elie Mamane wrote on Mon Nov 18 09:32:57 PST 2013 On Mon, Nov 18, 2013 at 06:10:34PM +0100, Fernand Vanrie wrote: yep conversions are not the problem, its the exiting code who is broken in many places ? What exiting code? This Basic-Macros excerpt: oDlg.getControl(myDateField).date = CDatetoIso(now()) was broken in LibreOffice 4.1.1. The only known migration path is to adjust all broken places with: REM broken oDlg.getControl(myDateField).date = CDatetoIso(now()) dim oDat as new com.sun.star.util.Date with oDat .day = Day(now) .month = Month(now) .year = Year(now) end with oDlg.getControl(myDateField).date = oDat Now, if you have thousands LoC of Basic Macros, ... ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
On Mon, Nov 18, 2013 at 09:10:34PM +0100, David Ostrovsky wrote: Lionel Elie Mamane wrote on Mon Nov 18 09:32:57 PST 2013 On Mon, Nov 18, 2013 at 06:10:34PM +0100, Fernand Vanrie wrote: yep conversions are not the problem, its the exiting code who is broken in many places ? What exiting code? This Basic-Macros excerpt: oDlg.getControl(myDateField).date = CDatetoIso(now()) was broken in LibreOffice 4.1.1. The only known migration path is to adjust all broken places with: REM broken oDlg.getControl(myDateField).date = CDatetoIso(now()) dim oDat as new com.sun.star.util.Date with oDat .day = Day(now) .month = Month(now) .year = Year(now) end with oDlg.getControl(myDateField).date = oDat Now, if you have thousands LoC of Basic Macros, ... I had understood exiting code as the return value of a procedure, so I was completely lost as to what was meant. I now understand that Fernand meant exiSting code, where code is not a value (a number / string), but a piece of program. On a sidenote, oDlg.getControl(myDateField).date = CDatetoIso(now()) can be replaced by oDlg.getControl(myDateField).date = CDateToUnoDate(now()) -- Lionel ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
Hi Thomas, *, Thomas Krumbein wrote (14-11-13 09:21) Because in LO 4.1 we have some API-changes, macros should now have a version-switch. There are different methods to get the internal version-number - that is not a problem. But: The version number itself is not suffcient because AOO 4.1.0 will start soon and this version-number is identical to LO 4.1.0. For the DocumentInfo - that changed from 3.x to 4.x, I use the following: If HasUnoInterfaces(ThisComponent, com.sun.star.document.XDocumentInfoSupplier) Then ' 3.x s = ThisComponent.Documentinfo.Keywords ' example Else s = ThisComponent.getDocumentProperties.Keywords(0) End If I've not yet been looking into details to possibly distinct between pré and after 4.1.0 for the Date . In general: Would be nice if for every API change there is something as I place above here, to check from e.g. the aivailable interface what to do. (Sidenote: the change in page formatting, that a page style can have different headers/footers on the first page in use, which is very positive for MsWord interoperability, may give a challenge too in code that manages printing: the page format as such could be used to distinct between various trays to print to. But that cannot be done in the same way now for documents using that feature ;) ) Cheers, Cor -- - Cor Nouws - http://nl.libreoffice.org - The Document Foundation Membership Committee Member ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
On 14/11/13 09:21, Thomas Krumbein wrote: Hey all, I am looking for an easy way to find out, which product (LibO or AOO) is installed and currently activ via Basic Macros. Because in LO 4.1 we have some API-changes, macros should now have a version-switch. i hope the API changes are small enough in scope so that you don't have to re-write everything? we try to do API changes only after a careful discussion of the alternatives; please give us feedback in case you think that you spend too much time and effort on this kind of thing :) There are different methods to get the internal version-number - that is not a problem. But: The version number itself is not suffcient because AOO 4.1.0 will start soon and this version-number is identical to LO 4.1.0. So macros must have additional a vendor-switch. Do somebody have an easy access hint to vendor-name? There should be a possibility in configuration-data, but I do not know where? searching for PRODUCTNAME finds this: http://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Setup.xcu#22 org.openoffice.Setup.Product.ooName value should be LibreOffice at runtime (or LibreOfficeDev for a non-release build). ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
Hey Michael, Am 15.11.2013 12:53, schrieb Michael Stahl: On 14/11/13 09:21, Thomas Krumbein wrote: Hey all, I am looking for an easy way to find out, which product (LibO or AOO) is installed and currently activ via Basic Macros. Because in LO 4.1 we have some API-changes, macros should now have a version-switch. i hope the API changes are small enough in scope so that you don't have to re-write everything? we try to do API changes only after a careful discussion of the alternatives; please give us feedback in case you think that you spend too much time and effort on this kind of thing :) Well, this change was a small technical thing - but with a very big influence on typical market applications. Every custom macro application with dialogs or forms for user interfaces is influenced if dialogs/forms using Date/time fields. And typicly most of them (in my applications about 70%) used those fields. So all applications will crash using LO 4.1.1.2 or upper. So in my opinion nobody who make this decision has a closer market view. Do somebody have an easy access hint to vendor-name? There should be a possibility in configuration-data, but I do not know where? searching for PRODUCTNAME finds this: http://opengrok.libreoffice.org/xref/core/officecfg/registry/data/org/openoffice/Setup.xcu#22 org.openoffice.Setup.Product.ooName Thanks for this - I know the xcu files. But this is not an easy access for (Basic-) macros. The way to do is: Search for this file, parse this file and extract the vendor name... for basic marcos a very long way. I can find a solution - but I think about all those macro-programmers out in the market: Do you really think, this is a real solution? Thank you an d best regards Thomas -- ## Unterstützung der freien Office Suite ## http://de.libreOffice.org - www.LibreOffice.org ## Vorstand Freies Office Deutschland e.V. ## Mitglieder willkommen: www.FroDeV.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
Hi, On Fri, Nov 15, 2013 at 01:43:38PM +0100, Thomas Krumbein thomas.krumb...@documentfoundation.org wrote: Thanks for this - I know the xcu files. But this is not an easy access for (Basic-) macros. The way to do is: Search for this file, parse this file and extract the vendor name... for basic marcos a very long way. Why not use the css::configuration::ConfigurationProvider API instead? I mean something like: oProvider = createUnoService(com.sun.star.configuration.ConfigurationProvider) Dim aParams(0) As new com.sun.star.beans.PropertyValue aParams(0).Name = nodepath aParams(0).Value = /org.openoffice.Setup/Product oSettings = oProvider.createInstanceWithArguments(com.sun.star.configuration.ConfigurationAccess, aParams) xray oSettings.getByName(ooName) HTH, Miklos signature.asc Description: Digital signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
On 11/15/2013 07:43 AM, Thomas Krumbein wrote: Every custom macro application with dialogs or forms for user interfaces is influenced if dialogs/forms using Date/time fields. And typicly most of them (in my applications about 70%) used those fields. So all applications will crash using LO 4.1.1.2 or upper. Are you saying that if you use a Date / Time field in a form or dialog in LO, it fails? If there is more to it, can you be more specific, sorry if I am uninformed on this. -- Andrew Pitonyak My Macro Document: http://www.pitonyak.org/AndrewMacro.odt Info: http://www.pitonyak.org/oo.php ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
Hi Thomas, Thomas Krumbein píše v Pá 15. 11. 2013 v 13:43 +0100: Well, this change was a small technical thing - but with a very big influence on typical market applications. Every custom macro application with dialogs or forms for user interfaces is influenced if dialogs/forms using Date/time fields. Have you filed a bugreport, please? A minimal example of the macro that fails would be most appreciated. Thank you, Kendy ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
Hey Kendy, Am 15.11.2013 15:35, schrieb Jan Holesovsky: Hi Thomas, Thomas Krumbein píše v Pá 15. 11. 2013 v 13:43 +0100: Well, this change was a small technical thing - but with a very big influence on typical market applications. Every custom macro application with dialogs or forms for user interfaces is influenced if dialogs/forms using Date/time fields. Have you filed a bugreport, please? A minimal example of the macro that fails would be most appreciated. Well - it´s not a bug, because you mentioned the change in release-notes of version 4.1. What´s happend, you can read my article on my homepage. It is in german language but I am sure, you get the context ;) http://www.mic-consulting.de/index.php/opersource/api-makros-libo-aoo/10-datumsfelder-geaendert-in-lo-4-1-1 Best regards Thomas -- ## Unterstützung der freien Office Suite ## http://de.libreOffice.org - www.LibreOffice.org ## Vorstand Freies Office Deutschland e.V. ## Mitglieder willkommen: www.FroDeV.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
Hi Miklos, yes, thanks, that might be a practible way at this time. Nevertheless - it is not a solution for the future. I guess, there should be an implementation of the original product name, version-number (major and minor) and actuall product name. This should be easy accessible even for unexpierienced macro developers. I will do a feature request or this :) best regards Thomas Am 15.11.2013 14:11, schrieb Miklos Vajna: Hi, On Fri, Nov 15, 2013 at 01:43:38PM +0100, Thomas Krumbein thomas.krumb...@documentfoundation.org wrote: Thanks for this - I know the xcu files. But this is not an easy access for (Basic-) macros. The way to do is: Search for this file, parse this file and extract the vendor name... for basic marcos a very long way. Why not use the css::configuration::ConfigurationProvider API instead? I mean something like: oProvider = createUnoService(com.sun.star.configuration.ConfigurationProvider) Dim aParams(0) As new com.sun.star.beans.PropertyValue aParams(0).Name = nodepath aParams(0).Value = /org.openoffice.Setup/Product oSettings = oProvider.createInstanceWithArguments(com.sun.star.configuration.ConfigurationAccess, aParams) xray oSettings.getByName(ooName) HTH, Miklos -- ## Unterstützung der freien Office Suite ## http://de.libreOffice.org - www.LibreOffice.org ## Vorstand Freies Office Deutschland e.V. ## Mitglieder willkommen: www.FroDeV.org ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
Just to point you to some other options. The basic library Tools that comes with LibreOffice contains a few interesting macros related to this. You need to load the library first then you can use GetProductName. BasicLibraries.LoadLibrary(Tools) msgbox GetProductName If you need more detailed information you can look in the registry (xcu-files) using the helper-function GetRegistryKeyContent. BasicLibraries.LoadLibrary(Tools) oKey = GetRegistryKeyContent(/org.openoffice.Setup/Product) msgbox oKey.ooName msgbox oKey.ooSetupVersionAboutBox The GetRegistryKeyContent basically does what Milkos did for you. Use xray to inspect oKey for more possibilities. These functions is available in AOO as well. Regards, Niklas Johansson Thomas Krumbein skrev 2013-11-15 15:49: Hi Miklos, yes, thanks, that might be a practible way at this time. Nevertheless - it is not a solution for the future. I guess, there should be an implementation of the original product name, version-number (major and minor) and actuall product name. This should be easy accessible even for unexpierienced macro developers. I will do a feature request or this :) best regards Thomas Am 15.11.2013 14:11, schrieb Miklos Vajna: Hi, On Fri, Nov 15, 2013 at 01:43:38PM +0100, Thomas Krumbein thomas.krumb...@documentfoundation.org wrote: Thanks for this - I know the xcu files. But this is not an easy access for (Basic-) macros. The way to do is: Search for this file, parse this file and extract the vendor name... for basic marcos a very long way. Why not use the css::configuration::ConfigurationProvider API instead? I mean something like: oProvider = createUnoService(com.sun.star.configuration.ConfigurationProvider) Dim aParams(0) As new com.sun.star.beans.PropertyValue aParams(0).Name = nodepath aParams(0).Value = /org.openoffice.Setup/Product oSettings = oProvider.createInstanceWithArguments(com.sun.star.configuration.ConfigurationAccess, aParams) xray oSettings.getByName(ooName) HTH, Miklos ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Vendors Name via UNO API / Basic Macros
Andrew , the problem is : stardiv.Toolkit.UnoDateFieldControls who has until 4.0 a date property who is a ISO representation of the datevalue. Since 4.1 this date property is a structure (day, month, year) who is more handy but painfull for us with hundreds of code lines using the isovalue. i signaled this already to Lionel, but he he is working hard to solving other base problems, i supose e we should fil a Regresion issue for this ? On 11/15/2013 07:43 AM, Thomas Krumbein wrote: Every custom macro application with dialogs or forms for user interfaces is influenced if dialogs/forms using Date/time fields. And typicly most of them (in my applications about 70%) used those fields. So all applications will crash using LO 4.1.1.2 or upper. Are you saying that if you use a Date / Time field in a form or dialog in LO, it fails? If there is more to it, can you be more specific, sorry if I am uninformed on this. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
