Issue 17784

Summary: Strange behaviours of old basic objects
Product: udk Reporter: paolomantovani <p_manto>
Component: codeAssignee: AOO issues mailing list <issues>
Status: ACCEPTED --- QA Contact:
Severity: Trivial    
Priority: P5 (lowest) CC: issues
Version: OOo 1.1 Beta2   
Target Milestone: AOO PleaseHelp   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---

Description paolomantovani 2003-08-02 01:54:32 UTC
REM  *****  BASIC  ***** 
'the code below shows some strange behaviours 
'of the interpreter when you use names of 
'basic libraries as they would be objects 
Option Explicit 
Sub OldObjects 
Dim Obj As Object 
	Set Obj = tools 
	Print Obj.Name 
	Print tools.gimmicks(,,,,,) 
	Print schedule.gimmicks(,tools,).tools.thiscomponent.dbg_properties 
	'if a library is loaded, also modules names  
	'can be use	 
End Sub
Comment 1 kay.ramme 2003-08-04 12:02:35 UTC
Andreas, please take care of this and retarget accordingly (OOo2.0?)
Comment 2 ab 2003-09-01 13:35:30 UTC
-> OOo 2.0
Comment 3 2004-05-18 14:47:34 UTC
According to the roadmap of 2.0
( this
issue has been scheduled for 3.0. 
Comment 4 ab 2005-07-28 11:18:46 UTC
So what? Is any specification violated by this Basic behaviour?
No one has to use undocumented properties and if he does,
he can't complain about the result.

-> Completely uncritical, -> P5, probably WONTFIX
Comment 5 paolomantovani 2005-07-28 12:02:17 UTC
I'm surprised and sorry to hear this from you. 
You'll consider me a nitpicker but I think that this kind of things makes the 
difference between a toy and a professional tool    
Comment 6 ab 2005-08-12 08:10:29 UTC
Hi Paolo,

sorry, obviously I have phrased my comment too harshly. It really 
wasn't my intention to accuse you beeing a nitpicker.

So I want to give some more background information how I rank the 
priority of tasks. In general for me tasks that prevent _correct_ 
(taking VB as reference) programs from running are far more criti-
cal than tasks that describe the strange behaviour of a even more
strange Basic macro. This task is a perfect example for the latter.

Of course it would be nice if even things like this could be fixed
and maybe you're right that this makes OOo Basic looking more pro-
fessional. But when I started scanning my Basic issues some weeks 
ago, I had more then 90. I could mark many as double or invalid
and could also fix some, but nearly all of the remaining 60 issues
are far more critical than this one, because they can really break
a correct Basic program or behave incompatible to VB.

But I do even fix issues I consider to be uncritical, if the fix is 
easy and without risk. So I just fixed your i17826 "Basic: flaws 
in the colored syntax" that I also consider to be very uncritical. 
But here a fix probably would be much more difficult and risky be-
cause it touches mechanisms and implementation details in the dee-
pest Basic core. And I had to learn that it's better to be _very_
careful there. So I think fixing this task is simply not worth the
risk and effort.

Nevertheless I appreciate your critical view. Please continue to
nitp... - ooops ;-) - to analyse the OOo Basic behavior precisely.
I just can't promise to fix everything. Problems like this most 
probably will only be fixed if the fix is _very_ easy.


Comment 7 paolomantovani 2005-08-19 17:06:56 UTC
thank you for your kind reply.    
I must say that I agree on almost everything you said. 
Sure I agree with P5 and even P10 if it would exist :-) 
But nevertheless I would like that this small issue would be fixed, first or  
Anyway here the "problem" is not   
"correct code does not work" but  
"incorrect code does work" that is much different and less severe. 
Therefore I can understand your point of view and I will not reopen the issue 
if you will close it 
Comment 8 Marcus 2017-05-20 11:29:23 UTC
Reset assigne to the default "".