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
[email protected]
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! --
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
