Re: MSVC++ app type choice, form design questions

In article <pwH5e.2752$go4.468@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
frnak@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx says...

[ ... ]

> At startup the end user sees a summary of the database contents.
> Editing (that 10% of the code that will take 90% of the work) is
> reached through buttons that change the face of the app's main
> screen. Click [Here] and you can browse through the X records (and
> optionally edit them), clock [There] and you do the same thing with
> the Y records.

Do you want to support X records and Y records being open at the same
time? If so, MDI might be a reasonable choice. If you're only going
to allow one to be open at a time, I'd probably think about using a
static splitter with the summary in the left pane (or perhaps upper
pane) and in the other pane dynamically opening the records selected
in the summary pane.

> Hardly original, but it's pretty straightforward, and I'm hoping
> it's an approach that most of the end-users will pick up on fairly
> quickly.

Sounds reasonable to.

> I hadn't using MDI, with a form for each "screen", though. Thanks
> for the suggestion.

Just keep in mind that it may or may not make sense -- it's mostly a
question of whether you want to be able to open several things
simultaneously, each more or less equal to the others.

[ ... ]

> Okay. I know I'll have to lay out the screens on paper (and in a
> lot more detail than the "mockups" I've shown the customer) before
> really beginning the application itself.

I'm not sure that's a particularly good idea. I haven't laid out a
form on paper in _years_ (though I'll admit I don't spend most of my
time doing database stuff). The problem is that paper is basically a
static medium, and doing the design on paper often seems (at least to
me) to produce a fairly static design -- the individual forms are
often nice to look at, but the design as a whole ends up somewhat
clumsy. In particular, paper makes it relatively difficult to include
things like when particular buttons should be disabled, or when a
button's label should be changed.

Given the ease with which forms can be rearranged, I'd tend more
toward the XP style of development -- start with a minimal
implementation of a minimal spec, and then embellish from there based
on feedback from the users. If you do a detailed layout on your own,
it's probably going to be wrong anyway -- and I do NOT mean that as
an insult; nobody else could get it right either...

[ ... ]

> Turns out that if one Searches the hard drive one discovers that the
> MSVC++.NET.2k3 package doesn't actually include MSDE,

Oh, I guess I should have known better than to assume _anything_
about VS.NET was done right! :-)

> but there _is_
> a README file saying it can be downloaded from the following URL:
>
> http://go.microsoft.com/fwlink/?linkid=13962
>
> Oh, and it's a 70Mb download. I have this sudden image of
> delivering a 250K application with 20Mb of SQL Server DLLs...

That's what I'd call an _extremely_ high level of code reuse!

[ ... ]

> Okay. If I can access and update it, there's agood chance I can
> create it afresh as well. Oh... and _compact_ the sucker. I'd
> forgotten that .mdb files need to be compacted periodically.

Yet another reason to use MSDE instead. Even if we assume it used an
extra 100 MB of disk space, that costs roughly a nickel at current
hard drive prices. At the current US minimum wage, that's equivalent
to roughly 30 seconds...

> They're mentioned, but (as with the other data sources) it was in
> the context of getting access to them. it was't clear if one could
> create and/or update dBase/FoxBase files as well without additional
> software.

You can definitely update them, but I'm not sure about creating them.
About the only reason I can think of to use them in the first place
would be to connect to an existing one.

[ ... ]

> Hm. I'd better look through the examples that came with the package
> a little better. It looked a lot more complicated... but then,
> that was a whole _week_ ago. <grin>

I probably should have qualified this -- I've never written anything
to talk to a database with VS.NET 2003. VS.NET has broken nearly
_lots_ of things that worked really nicely in VS 6, so it may easily
be that this is much more difficult as well. While I'll admit to
being considerably less expert wit the newer versions, I did a bit of
experimenting, and it looks like it has gotten more difficult.

In VS 6, it's dead simple:

1) In the AppWizard select "database view without file support".
2) In the same page, select an ODBC or DAO data source.
3) Open the dialog in the dialog editor.
4) Add (usually edit) controls for the database fields.
5) Control+double-click in each control and select its field from the
drop-down list. A field 'Field1' will show up as 'm_pSet->Field1'.

This produces a simple browsing program -- i.e. one record at a time,
no searching, reports, etc., but it does get data from the database
(and doing a quick check, contrary to my recollection, it does allow
you to do updates too).

Of course, for most real applications you need/want to add more than
that, but something simple like that was about as easy in VS 6 as in
something like Access -- which is probably why they broke it.

Of course, I'm talking about doing the job in MFC -- every time I try
to use the .NET stuff, I end up getting frustrated, though I seem to
recall having heard of a free component from MS to make data access
easy under .NET, but I'm afraid I don't remember any details beyond
that (and knowing how things go, that description might easily apply
to a half dozen different things if you look...)

[ ... ]

> Mostly what I remembered was better support for shuffling components
> around on a dialog/window whenever needed without it having much
> effect on the underlying code.

Moving, resizing, etc., controls on a dialog shouldn't require any
code changes in either case.

--
Later,
Jerry.

The universe is a figment of its own imagination.
.

Loading