Before I begin describing the bug, I'll be honest and admit that my native programming language is C++. I haven't learnt BASIC properly, I don't have any proper experience in it and honestly I'm not a huge fan of it, at least, not from what I've seen so far. However in spite of my bias and naïvety, I was only trying to write a very basic function and I still think this can be considered a valid problem that would help programmers of all sorts if it were fixed. I have distilled the problem to the following very basic program: Sub TestVariant(Arg1) msgbox("typename", TypeName(Arg1), "is numeric", Arg1.IsNumeric()) End Sub sub Main Dim int As Integer, var As Variant var = 4 int = 4 TestVariant(4) 'The program will stop upon the first of these TestVariant(int) 'three calls. If the order is changed, it will TestVariant(var) 'happen for each one ie the error occurs equally 'passing a constant, an integer, and a variant 'as a variant End Sub The error with my code is that IsNumeric is not a member function of Variant (actually does it have any member functions at all?); I should have used the global function isNumeric() but as I didn't come across this online I instead found the VB equivalent. However the error message that is shown is "Object variable not set". I have found very little information about this error online, so I would presume that the problem is what it says on the tin, that a variable is not set. The debugger produces the message when stepping into the function and so stops on the line of the sub and argument declaration. Looking in the watches window, currently when I reproduce the situation the type of Arg1 is Object and the value is Null, however I am sure that when I have encountered it in the past the type was Variant/Empty. The error message, the null value and the error message therefore led me to believe that there was an error in passing the arguments into the function and converting them to variants, so I modified the argument lists to no avail. It was only when I found the e-book 'Useful Macro Information for OpenOffice.org' by Andrew Pitonyak that I got the idea that the problem might not be with the value itself but with the member functions. Distilling the problem even further, the following produces the same error message, although the debugger stops on the line with the function call, and the value and type of the variant are displayed correctly in the watchlist: Sub Main dim V as Variant V = 5 V.octocats() End Sub Compare this to the behaviour with the following code: Sub Main dim oCurrentSelection as Variant oCurrentSelection = ThisComponent.getCurrentSelection() oCurrentSelection.octocats() End Sub The message output is "Property or method not found:octocats", the value is displayed correctly in the watchlist and the debugger stops on the line of the function call. In summary, below is what I see and what it implies to me about the cause of the error: :: "Object variable not set" -> The problem is with the initial setting of the variant to a valid value and not with what I do with the variant afterwards. :: When calling a sub, the debugger stops on the argument list -> The argument hasn't been passed correctly; the problem is with the argument list, e.g. specifying values where references should have been used, or the caller can't convert the given argument to a variant, or something along those lines. :: When calling a sub, the watch for the variant sometimes shows the type as object -> The variant hasn't been initialised properly, similar to the above :: When calling a sub, the watch for the variant shows the value as null -> As above, the variant was never initialised properly and the problem is in passing the arguments, where this initialisation occurs Below is what I believe should happen: :: At least, the message should state either something like "Property or method not found: IsNumeric" or "Variant does not support member access" or if the member operator is being "redirected" to an object being stored in the variant "Variant value is not of type Object" :: When calling a sub, the debugger should stop on the offending line in the function body rather than on the sub's stub. :: If possible, the value and type of the variant should be displayed as they would be if the offending statement were removed, up until the offending statement, i.e. the value is shown correctly before accessing an invalid member. I can try reproducing this in a newer version of LO however I'm posting this before I replace the package in case I break my package manager in doing so. It shouldn't happen but before when I've upgraded a package apt has asked me to upgrade all the dependencies because the package was compiled with those, which realistically won't have broken compatibility between minor version numbers, such as the C runtime library. My OS is Linux Mint Petra AMD64
@Noel - I think you would be most qualified to answer this one - not sure if anyone in QA would be comfortable doing so. BTW - you have two registered names in bugzilla - if you want me to delete one send me an email and I'll try to do so :)
(In reply to Joel Madero from comment #1) > @Noel - I think you would be most qualified to answer this one - not sure if > anyone in QA would be comfortable doing so. > iiuc then this error is correct and matches what MS vba does/says (note: I don't currently have access to any MS Office versions to check) There seems multiple issues described here, I wont bother trying to decipher them, if there are separate issues then there should be separate bugs. My response here is for the issue in the subject only, e.g. "Object Variable Not Set" error when member not defined for Variant Again (iirc) this is the standard VB error in this scenario, the first example above assigns a 'basic type' e.g an 'Integer' and a Variant containing an Integer respectively. That type (e.g. Integer or Variant) is passed to the 'TestVariant1' subroutine as a 'Variant' type, note: Arg1 has no type so it will be treated as a Variant. Also Note: a Variant is an opaque type, it's a sortof container for 'any' type you assign to it, when you try and call a method on a Variant it 'knows' you are trying to call on the 'Object' contained by the 'Variant' In the example above the 'Object' assocated with that 'Variant' type is 'NULL' as the real types passed are basically primitive types. The error reflects 'Basics' understanding of the situation and it is telling you there is no Object associated with the Variant. The reason why the second example gives a different error is that 'oCurrentSelection' *IS* an object and the Variant in this case does infact have an object instance that it tries to call a method on. If the method (or property) does not exist for the object you are trying to call on it reports that fact. I see there are other comments about the debugger stopping at the function (implying it doesn't actually get to the real error) that sounds very suspicious, if that is happening that would be a bug imho
(In reply to Noel Power from comment #2) > (In reply to Joel Madero from comment #1) > > @Noel - I think you would be most qualified to answer this one - not sure if > > anyone in QA would be comfortable doing so. > > > iiuc then this error is correct and matches what MS vba does/says (note: I > don't currently have access to any MS Office versions to check) > > There seems multiple issues described here, I wont bother trying to decipher > them, if there are separate issues then there should be separate bugs. My > response here is for the issue in the subject only, e.g. "Object Variable > Not Set" error when member not defined for Variant > > Again (iirc) this is the standard VB error in this scenario, the first > example above assigns a 'basic type' e.g an 'Integer' and a Variant > containing an Integer respectively. That type (e.g. Integer or Variant) is > passed to the 'TestVariant1' subroutine as a 'Variant' type, note: Arg1 has > no type so it will be treated as a Variant. Also Note: a Variant is an > opaque type, it's a sortof container for 'any' type you assign to it, when > you try and call a method on a Variant it 'knows' you are trying to call on > the 'Object' contained by the 'Variant' In the example above the 'Object' > assocated with that 'Variant' type is 'NULL' as the real types passed are > basically primitive types. The error reflects 'Basics' understanding of the > situation and it is telling you there is no Object associated with the > Variant. The reason why the second example gives a different error is that > 'oCurrentSelection' *IS* an object and the Variant in this case does infact > have an object instance that it tries to call a method on. If the method (or > property) does not exist for the object you are trying to call on it reports > that fact. > > I see there are other comments about the debugger stopping at the function > (implying it doesn't actually get to the real error) that sounds very > suspicious, if that is happening that would be a bug imho Okay, With regards to where the debugger actually stops, I've submitted a new bug report: https://bugs.documentfoundation.org/show_bug.cgi?id=91780 With regards to the error message itself, I was thinking of closing this off and opening a new bug suggesting more detailed error reporting for BASIC runtime errors. I appreciate the need to copy VBA's behaviour so I wouldn't suggest changing the message but I've also written a few macros using VBA and the error messages leave a lot to be desired so I think in this case it would be great if LO could go one step further and do better than Microsoft. I was thinking of suggesting a more detailed comment in addition to the error title detailing what the error means and if appropriate, giving information specific to the situation that caused the error to be generated, and/or an error code and/or a link to a help page detailing what can cause the error and what can be done to resolve it. Would this be okay with you? Thanks, stellarpower.
Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping-20180302
Dear Bug Submitter, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-20180404