To comment on the following update, log in, then open the issue:
http://www.openoffice.org/issues/show_bug.cgi?id=88878





------- Additional comments from [email protected] Tue May  5 13:35:36 
+0000 2009 -------
Hi Frank, eventually I have got around to looking at this ( sorry, I know it is
a long time ) but lets push on this again

Here is what I have done regarding you previous review comments of the patch, I
descrbe them in order

1) - PROPERTY_VISIBLE should be renamed to PROPERTY_ENABLE_VISIBLE....

Action: Done btw. I don't agree that VISIBLE needs to change to ENABLE_VISIBLE
which I find confusing, I am quite happy to accept that the model's 'VISIBLE'
state is the desired ( and persisted ) state. I am equally happy to accept that
this state is not honoured in all cases ( the obvious one design mode where I
would expect the control to be visible regardless of the state of enable visible
).... but this is just my opinion and it is not imo a real important issue

2) + toolkit/source/helper/property.cxx....

Action: done

3) - mbDirectVisible should be a member of VCLXWindowImpl....

Action: done

4) + when a VCLXWindow is created, a subsequent call to VCLXWindow::SetWindow...

Action: done 

5) + VCLXWindow::setVisible: I suppose mbDirectVisible needs to be set in every
case.....

Action: Done

6) + VCLXWindow::setProperty: I am not sure the current behavior of setting the
visibility is correct.....

Action: done

7) + VCLXWindow::ImplGetPropertyIds:
  I suppose the addition of BASEPROPERTY_VISIBLE to rIds belongs
  into the "if( bWithDefaults )" branch. I am not completely sure
  about this, since I do not know those relatively new ImplGetPropertyIds
  methods too well.

Action: not done, for some dialog controls at least it seemed ( with a test )
you need to specify the propery ids ( they don't get picked up with the
bWithDefaults ). I'm afraid I was a little lazy and just err'ed on the side of
caution and added BASEPROPERTY_ENABLEVISIBLE everywhere BASEPROPERTY_ENABLE is 
used 

8) + VCLXWindow::draw the isEnableVisible should be used more generous...

Action: done

Additionally you will notice some tweaking to enable EnableVisible in the forms
module for some controls that seem not to use the awt base classes ( see to be
attached test document too ) 

Regarding the issue of when the model says false and we are in design mode that
you mentioned, I think it would be enough to just ignore ( e.g. consider
'enablevisible' to be true ) and just show the control. Indicating somehow it
will be invisible when alive seems like overkill. But.. I do think it is
necessary to show the control when in design mode ;-) otherwise clicking in
various parts of the document to try and find the now invisible control is not
much fun ;-) ( which is what happens currently, but perhaps this is to do with
the milestones I am using? ). In anycase I did try modify the Show methods in
vclxwindow.cxx to take this into account and it *mostly* worked but it seemed
when resizing the control (in design mode of course ) the "green boxes" that
mark the edges of control and the drawing/graphic representation of the control
don't move or resize when dragging with the mouse, of course when you release
the mouse it is resized etc. :-( Some little advise here on what to do would be
good for someone as vcl/drawing ignorant as I

With basic dialogs there are still some open items. As you mentioned there is
the issue of the step, I need to look at the code for that, but... it seems that
a test something like ( ( controlStep == 0 || controlStep == dialogStep ) &&
bEnableVisible ) controlling the visibility probably is close to what we need in
alive mode and in design mode I think like mentioned earlier it would be enough
for the 'enablevisible' to be ignored ( e.g. considered to be always true ).
Finally there is no provision for either persistence of the EnableVisible state
for Dialogs or the appropriate hooks for the MS Userform import filter to set
'EnableVisible'. I have a patch for the persistence ( dialog xml ) and import
filter that I will attach later ( do you think a seperate bug is needed ? ) 



---------------------------------------------------------------------
Please do not reply to this automatically generated notification from
Issue Tracker. Please log onto the website and enter your comments.
http://qa.openoffice.org/issue_handling/project_issues.html#notification

---------------------------------------------------------------------
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]

Reply via email to