[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[PROTEL EDA USERS]: Dialog box design (ex Re: help with design rule edit hang)
<snip>
> Things may get better eventually, in the mean time I would rather Protel
> fixed their ridiculous resource usage problems. It is a well known issue
> with Delphi/CBuilder and there are relatively simple fixes.
>
> Terry Harris
I agree, to a qualified extent, with what you are saying. Protel has
indicated that they will attempt to keep their product usable with consumer
versions of Windows for as long as possible, which suggests that while they
might not go overboard in retaining this capability, they will make at least
some effort in this regard.
My belief (which you can challenge if you consider appropriate) is that
there are trade offs to be made between having dialog boxes which are "user
friendly" to navigate/configure and minimising the amount of memory required
to implement these. In some situations, the ideal, from the user's point of
view, would be to have a single dialog box, with all of the controls in the
*same* Tab (so avoiding the need to select different Tabs in turn to access
different controls), and to have no controls in "child" dialog boxes (which
would require a greater number of clicks, and more time, to access). Such
dialog boxes could be implemented without memory problems if the user was
using Protel with a professional version of Windows, but could be
problematic if the user was using a consumer version of Windows instead.
But if the objective is to keep Protel usable with consumer versions of
Windows (as is the case for the vast majority of applications designed for
use with Windows), then there are some dialog boxes which would have to be
implemented in a form which reduces the associated memory requirements, even
if doing so reduces the degree of "user friendliness".
I have no personal experience with them, but I understand that there are
techniques available for reducing the memory requirements of dialog boxes
(such as using multiple Tabs, and creating only those controls which are in
the currently selected Tab, and destroying all controls in the previously
selected Tab). *If* these are straightforward to implement, *and* they are
not likely to introduce new bugs, then I agree that Protel should be making
use of these. (It is not out of the question that they are either using
these already, or are otherwise planning to make use of these in the
future.) However, I do wonder how straightforward it would be, in practice,
to adopt these measures (or to "retrofit" these to previously designed
dialog boxes). As such, I am ambivalent about Protel devoting too much time
to reducing the memory requirements of dialog boxes; I would tend to favour
a scenario where more bugs are fixed (*if* the dialog boxes are no more
problematic than is the present case) to a scenario where the dialog boxes
require less memory, but (as a tradeoff) fewer bugs are fixed.
However, if you have good reason to believe that it would be relatively
straightforward for Protel to adopt such techniques, then I strongly
recommend that you contact them directly, and provide them with sufficient
details to enable them to follow through. (Although they perceive their
product as being designed for use by professionals, they are aware that many
of their users are using this with consumer versions of Windows. As such,
they should not be adverse to receiving suggestions on how they can keep
their product usable with these versions.)
If you want to expand more (to Protel users) on how Protel could reduce the
memory requirements of dialog boxes, then I suggest that you consider doing
so on the Developers' forum rather than this forum. It is probable that
those who would be interested in anything you have to say on this matter are
already signed up with that forum.
Regards,
Geoff Harland.
-----------------------------
E-Mail Disclaimer
The Information in this e-mail is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this
e-mail by anyone else is unauthorised. If you are not the intended
recipient, any disclosure, copying, distribution or any action taken
or omitted to be taken in reliance on it, is prohibited and may be
unlawful. Any opinions or advice contained in this e-mail are
confidential and not for public display.