Jimmy wrote:

> Mathias Bauer schrieb:
>> Jimmy wrote:
>>
>>   
>>> I'm developping a component for Writer which has been tested with 
>>> Windows and works fine on different machines with different OpenOffice 
>>> Versions starting from 2.0.2 to 2.0.4.
>>>
>>> Now that I'm almost finished with it, I wanted to test the tool on a Mac 
>>> and on Linux. Surprisingly it failed and I don't really understand how 
>>> this could happen.
>>>
>>> On Linux (Gentoo) with OO.org 2.0.3 and 2.0.4 it fails and on Mac 
>>> (Intel/PowerPC) it fails with NeoOffice (OO.org 2.0.3). The main problem 
>>> which I figured out is on startup where the JobExecutor initializes 
>>> several things.
>>>
>>> The following code works with Windows but not with the other ones:
>>> xComponent = xDesktop.getCurrentComponent();
>>>
>>> xDesktop has been initialized but getCurrentComponent() doesn't give 
>>> anything back, it does so with Windows! (How is this even possible?)
>>>     
>>
>> getCurrentComponent() is not reliable as it depends on the
>> focus/activation handling on the particular OS. Unix systems are well
>> known to handle focus changes asynchronously so you have a good chance
>> that directly after starting the first window of OOo
>> getCurrentComponent() will be empty.
>>
>> If you want to work reliably use APIs that return you the objects that
>> you need.
>>
>> In your code:
>>
>>   
>>>         xController = xModel.getCurrentController();
>>>     
>>
>> This if fine, you have all you need: the model and the controller of the
>> document you want to work on.
>>
>>   
>>>         xComponent = xDesktop.getCurrentComponent();
>>>     
>>
>> Why do you need this at all? Even on Windows it won't give you anything
>> you don't have already.
>>
>> Or did I misunderstood your code?
>>
>> Best regards,
>> Mathias
>>
>>   
> So that would lead me to the following code in order to get the 
> xComponent and the xFrame.
> 
> xComponent = xModel;
> xFrame = xController.getFrame();
> 
> It did fix the problem although the behaviour with the frame 
> handling/opening is still different. But I guess I'll have to rework my 
> workflow then.

Yes, you will face the same problems as we have internally in the
application framework code. In a cross platform application the last you
can rely on is focus and activation handling.

Never use anything like "current...." or "active..." if you can't cope
with an empty or unexpected result. Code that just takes anything it
gets here can use methods like these successfully but code that assumes
to follow a defined workflow will fail using them.

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]

Reply via email to