Documentation and resizable window

[Éric Miclo]

Hello Richard,

Well, my app has several windows that can be closed except the first  
and main window that has to stay opened.
So I maid some modifications: the main window retains its close box  
but when clicked an answer dialog says that the app will be closed  
too if that window is closed (you can actually cancel it).
I'll hide the close box again when/if the bug is squashed.

In the mean time things will live so.

Regards,

ÉrIC

Le 19 juin 05 à 11:08, Richard Gaskin a écrit :

> Éric Miclo wrote:
> >>> I took a look at bug 2585 and I don't understand why you only set
> >>> it  as a normal bug. I find it more severe.
> ...
> >> Yeah, I'd like greater convenience too, which is why I posted  
> the  BZ
> >> report.  But even with a little scripting now and then I still   
> have
> >> righer ROI than I've had with any other tool I've used before.
> ...
> >> That particular issue is marked as "normal" because it can be
> >> completely resolved by pasting a short scipt (see my previous  
> post).
> ...
> > The time you loose is not in writting the code, but in finding  
> why it
> > doesn't work as expected.
> > I have the habit to think that I did something wrong before thinking
> > it's a bug in the tool I use (perhaps a not so good habit :-)).
>
> I agree, and I believe that's a wise insight.  Most of the time I  
> spend debugging involves diagnostics -- once the root cause of an  
> issue is known it's often not hard to either fix it or work around  
> it, as you've done. But as you pointed out, getting to that point  
> is where the time gets lost.
>
> Perhaps the greatest value of Bugzilla is that it serves as a real- 
> time reality check, a way to quickly find out if an issue is known  
> or just one's own misunderstanding or a typo.
>
> And of course, in addition to Bugzilla there's this list.  If  
> something's not there and a solution isn't readily evident in your  
> code it never hurts to pass it by the folks here -- if it's the  
> engine they'll confirm that, and if it's your code they'll offer a  
> solution.
>
> I'd like to see the quality high enough that we don't ever need to  
> do that, but in this imperfect world most developers have to check  
> in with someone to see what's up with the issues they encounter.  I  
> see this with operating systems, drivers, and development tools  
> alike. It's not ideal, and it benefits everyone to keep raising the  
> bar, but in the meantime all I can offer as an outsider to the  
> process is a tip or two now and then when they might help. :)
>
> > Last thing, the workaround is only partial because you can't
> > disable the closeBox under Windows without disabling the
> > resizable of the stack and that means you'll have to write
> > your own code for resizing  stacks and add your own piece
> > of GUI to manage it.
>
> Yes, that part of the bug has no simple workaround, so if you need  
> to omit the closebox you're in a different situation indeed.
>
> Is there a way the workflow for that window could be designed such  
> that the close box is left in place?  In terms of the semantics of  
> the user interaction close boxes are commonly treated as synonymous  
> with a "Cancel" button -- could that apply to your window?
>
> --
>  Richard Gaskin
>  Managing Editor, revJournal
>  _______________________________________________________
>  Rev tips, tutorials and more: http://www.revJournal.com
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>
>

-- My NeXT computer will Be a Mac too! --