Board index » cppbuilder » Re: The Silent Majority

Re: The Silent Majority


2004-12-20 10:00:19 AM
cppbuilder74
Roddy Pratt wrote:
Quote
This is a lways a pain - I'd be interested in your solution. A number
of times I've shot myself in the foot by having two controls each
updating the other and thus generating an endless stream of OnChange
events...
One problem here is that you are acting on control changes, rather than
application state. If you have an underlying 'model' that your
controls interact with and observe, it is usually simpler to catch and
resolve the circularity.
You might want to Google up some info on the Model-View-Controller
pattern, MVC for short, and the simplified version Document/View.
Separating application state from presentation (GUI) is important for
any reasonably complex system, and just as possible in BCB as any other
environment. The difference is BCB makes is easy to follow dirty
shortcuts that skip this separation and put all logic into your forms.
Taking this least-resistance route is definitely storing up trouble as
your system grows.
AlisdairM(TeamB)
 
 

Re:Re: The Silent Majority

Oscar Fuentes wrote:
Quote
>C++ Builder can make user interfaces that are virtually
>impossible to create with VC++, or any other tool except
>Delphi.

Actually, the converse is true: the form designer paradigm is too
simple for building the most complex GUIs.
I disagree. Of course it might depend what you mean by complex but we
have a project with 187 forms. Users typically start it up when they
arrive at work then shut it down when they leave. Any application with
that number of forms that a user can spend all day 'inside' is surely
as complex as it gets :)
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: The Silent Majority

Randall Parker wrote:
Quote
Lately I've begun using frames in BCB to organize subsets of a form
into different frame classes.
Aye. We found those just over a year ago and I really wish it'd been
sooner. Have you found the 'Anchor' property yet? We found that in
early summer and really, really wish we'd found it sooner.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

{smallsort}

Re:Re: The Silent Majority

Andrue Cope [TeamB] wrote:
Quote
Randall Parker wrote:


>Lately I've begun using frames in BCB to organize subsets of a form
>into different frame classes.


Aye. We found those just over a year ago and I really wish it'd been
sooner. Have you found the 'Anchor' property yet? We found that in
early summer and really, really wish we'd found it sooner.
And then play with this and the Align property inside Frames. You'll see
a very nice bug, especially if the Align property of the frame itself is
set to alClient.
Finally, bring in inheritance in your frames and you'll start yelling at
the damn thing whenever you don't open the frames starting from the very
first ancestor...
 

Re:Re: The Silent Majority

Alisdair Meredith wrote:
Quote
One problem here is that you are acting on control changes, rather
than application state. If you have an underlying 'model' that your
controls interact with and observe, it is usually simpler to catch and
resolve the circularity.
Yes we found that. We have a form that allows the user to navigate
around a file system showing sector contents. It appears on the same
form as the directory tree and file view.
That means the controls that can affect which sector is being shown are:
Directory tree
File view
LSN (Logical sector number)
LCN (Logical cluster number)
PSN (Physical sector number)
VSN (Virtual sector number)
Then we have to support the idea that more than one file can own data
in a single sector (slack space is most common but ReiserFS actively
allows this) so the cursor position affects VSN (sector number within
file).
In the end we decided that the file view and directory tree would never
change no matter what you did with the sector view itself. That meant
we had to be able to invalidate and disable VSN movement if the cursor
was outside the current file and also if the user used one of the other
'xSN' controls to navigate outside of the file.
I spent a week last month working on this form and it's a lot better
but still has a few oddities.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: The Silent Majority

"Db" < XXXX@XXXXX.COM >wrote:
Quote
It is the best Win32 C++ development environment hands
down for the vast majority of Win32 applications, nothing
comes remotely close.
Unfortunately it is not C++ but a mix of C++ and Delphi. As for Win32 and C++ how can you write a GUI without VCL (Delphi) if you don't have a Resource Editor?
Quote

C++ Builder can make user interfaces that are virtually
impossible to create with VC++, or any other tool except
Delphi.

Yes, at the price of not being portable. BCB deads? Your code will die with him. This won't happen if VCL were written in C++.
Quote
Anything can be improved, and I hope Borland will make
massive improvements to C++ Builder. Now that they've
made this commitment, it's in their best interest.
I Agree. Starting from a better compiler, linker and IDE....
Bye, Luigi
 

Re:Re: The Silent Majority

OBones wrote:
Quote
And then play with this and the Align property inside Frames.
Yup. Been there, seen that.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:Re: The Silent Majority

Hello Olivier
"OBones" < XXXX@XXXXX.COM >wrote in message
Quote
And then play with this and the Align property inside Frames. You'll see a
very nice bug, especially if the Align property of the frame itself is set
to alClient.
Finally, bring in inheritance in your frames and you'll start yelling at
the damn thing whenever you don't open the frames starting from the very
first ancestor...
This sounds like it might be something we are likely to hit at some stage in
the future, are the details documented anywhere?
Reading the latest posts it seems we're not alone in completely rethinking
our UI during the past year or so of Borland's procrastinations. We've
switched to using frames too. We've also done a lot of work on standardising
on a core set of customised components, providing our own in-house styles
rather than setting VCL properties directly.
Des
 

Re:Re: The Silent Majority

Des O'Toole wrote:
Quote
Hello Olivier

"OBones" < XXXX@XXXXX.COM >wrote in message
news:41c69ccd$ XXXX@XXXXX.COM ...


>And then play with this and the Align property inside Frames. You'll see a
>very nice bug, especially if the Align property of the frame itself is set
>to alClient.
>Finally, bring in inheritance in your frames and you'll start yelling at
>the damn thing whenever you don't open the frames starting from the very
>first ancestor...


This sounds like it might be something we are likely to hit at some stage in
the future, are the details documented anywhere?
Not really, but basically, don't use Align on the frame itself or you
will "suffer".
You can set it at runtime, no drama there.
But setting it at designtime will mean that the components inside it
that use align or anchors will resize themselves weirdly. Most notably,
they will grow larger than the frame.
As to the inheritance problems, the symptoms are that when opening an
unrelated frame, it will complain about missing declaration for
components that are in the other frame. Really strange, but that's the
way it is. A bit like if the designer only knows of one frame type for
the complete project. Not much one can do here, but close the project
when this happens and then reopen it.
 

Re:Re: The Silent Majority

Many thanks Olivier, I'll pass the details on.
Des
 

Re:Re: The Silent Majority

Andrue Cope [TeamB] wrote:
Quote
Oscar Fuentes wrote:


>>C++ Builder can make user interfaces that are virtually
>>impossible to create with VC++, or any other tool except
>>Delphi.
>
>Actually, the converse is true: the form designer paradigm is too
>simple for building the most complex GUIs.


I disagree. Of course it might depend what you mean by complex but we
have a project with 187 forms. Users typically start it up when they
arrive at work then shut it down when they leave. Any application with
that number of forms that a user can spend all day 'inside' is surely
as complex as it gets :)
Absolutely. I have a project with over 700 forms (including
quickreports), which is likewise used by the end-users all day long. A
very large project, and I can't quite think of any type of "complex"
form that I wouldn't be able to make with BCB... In fact, it seems to me
that if it were indeed possible to make something more complex, it would
not be in the interest of the end-user... Who wants a complex GUI?
Jonathan Neve.
 

Re:Re: The Silent Majority

"Andrue Cope [TeamB]" < XXXX@XXXXX.COM >writes:
Quote
Oscar Fuentes wrote:

>>C++ Builder can make user interfaces that are virtually
>>impossible to create with VC++, or any other tool except
>>Delphi.
>
>Actually, the converse is true: the form designer paradigm is too
>simple for building the most complex GUIs.

I disagree. Of course it might depend what you mean by complex but we
have a project with 187 forms.
I was talking about complexity of a single form, and/or complexity of
relations between forms. OTOH, developing GUIs by code makes easier to
refactor and to apply design principles. Delphi makes easy to fall
into a serious of typical errors, like mixing GUI and bussiness
rules, careless design, etc.
Applications with such a big number of forms are a PITA to build and
maintain with the Delphi model. I'll prefer a global design and to
dynamically generate the forms from the metadata that describes the
problem.
[snip]
--
Oscar
 

Re:Re: The Silent Majority

Oscar Fuentes wrote:
Quote
I was talking about complexity of a single form, and/or complexity of
relations between forms. OTOH, developing GUIs by code makes easier to
refactor and to apply design principles. Delphi makes easy to fall
into a serious of typical errors, like mixing GUI and bussiness
rules, careless design, etc.
Yes, Forms based development requires a clear understanding of the
value of composition as well as inheritence, and breaking
large(complex) forms down into a composition of simpler aggregates is
often a good way of learning how/why to do this for general, non-GUI
development.
At least, that was my experience <g>
There is certainly a virtuous-circle of improved OO understanding
leading to cleaner form designs, returning an even deeper appreciation
of the OO fundamentals.
Quote
Applications with such a big number of forms are a PITA to build and
maintain with the Delphi model. I'll prefer a global design and to
dynamically generate the forms from the metadata that describes the
problem.
My problem with meta-data driven designs is that the ones I produce are
often bland and indestinct, often lacking 'obvious' behaviours that
might apply to a special case, but not easily generated out of the
metadata. Pushing all the customisation into the metadata quickly
produces a system so complex that no-one wants to put the (meta)data in!
You have clearly worked at this harder than I, so may well have solved
these problems too <g>I have found a mix of metadata-generated GUI
components, on RAD-based forms, gives me a best-of-both-worlds mix.
OK, maybe not 'best of' but 90% of the best of each, which is good
enough for me ;?)
AlisdairM(TeamB)
 

Re:Re: The Silent Majority

Oscar Fuentes < XXXX@XXXXX.COM >writes:
Quote
Delphi makes easy to fall into a serious of typical errors,
Delphi makes easy to fall into a *series* of typical errors,
--
Oscar
 

Re:Re: The Silent Majority

Alisdair Meredith [TeamB] wrote:
Quote
My problem with meta-data driven designs is that the ones I produce
are often bland and indestinct, often lacking 'obvious' behaviours
that might apply to a special case
That can happen, yes. We don't have any truly meta driven forms but we
do have a few standard menus that are automatically added to
components. For instance every listview in our application gets a
submenu with options to copy data to the clipboard. Similarly all edit
boxes and writeable memos get a Unicode submenu.
Both are added using a single function call in the form ctor.
They sound trivial but /everyone/ who's seen them thinks it's really
neat and makes the entire suite seem more professional. I suppose it
creates the impression that we spend a lot of time attending to
details. In truth we just did a search for TListView, TEdit and TMemo :)
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html