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

On Thu, 7 Apr 2005 23:40:42 -0600, Jerry Coffin <jcoffin@xxxxxxxxx> wrote:

Jerry,

Thank you for your comments.

>In article <pQm5e.2431$sp3.17@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
>frnak@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx says...
--snip--
>> 1) MSVC Project definition requires that for an MFC app I choose
>> between MDI, SDI, and dialog-based. At first I thought this
>> would be a dialog-based app, but it is possible that an SDI app
>> would be more appropriate. Can anyone point me at some examples
>> to help me figure out which makes more sense?

>Given what you've described (likelihood for multiple independent
>documents being open at a time), I'd probably go for MDI -- unless
>you plan to make all of them look like a single document visible in
>a single form.

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.

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.

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

>> Or is this one of those things that, unless you _need_ a
>> "document" drawing/printing/text editing window, really doesn't
>> matter much once your app gets beyond the "example" stage of
>> complexity?

>First of all, nothing you've mentioned makes it sound like your
>application is a whole lot more complex than some examples. :-)

Yeah, but it isn't included, at least not in _my_ copy of the MSVC++
product. (And if it were, I wouldn't make much on the contract...
on the other hand, my customer would be ecstatic!) Still, maybe I
should check again... <grin>

>MFC's built-in database support is really built around the document/
>view model, which simply isn't present in a dialog application --
>i.e. if you create it as a dialog app, you'll be doing nearly all
>the work in connecting to the database, etc. on your own -- unless
>you use a control to do the job (e.g. the MS Hierarchical FlexGrid,
>IIRC).

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. What I'm doing now is more
like "finger exercises" so I get a feel for how the pieces work --
or don't work -- together, and so I can discover whether I've made
any bad assumptions about my environment.

>> 2) MSVCC++.NET comes with access support for a number of database
>> environments. However, it's not clear from the documentation
>> how much of the support _comes_ with the MSVC++ package and
>> how much needs to be already present in the end-user's
>> environment.
--snip--
>It talks to databases using MDAC. MDAC has full built-in support
>for talking to an existing Oracle or Sybase server, but of course
>doesn't actually include the servers themselves.

And if MS didn't include them in the VC++.NET package, I probably
shouldn't ship them with my application. <grin>

>OTOH, MS does include a redistributable version of MS SQL server
>with VS. As you'd guess, it's carefully limited to keep it from
>competing with the full version of SQL Server, but it's still pretty
>usable -- databases up to 2 GB, and supports up to a dozen or so
>simultaneous users. I usually consider it preferable to Access
>tables (though you can use those as well).

Turns out that if one Searches the hard drive one discovers that the
MSVC++.NET.2k3 package doesn't actually include MSDE, 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...

>> What if Access had never been installed on the target machine?
>> Does MSVC++.NET provide all the DLLs I would need to access
>> and update the .mdb file? Could I include an empty .msb
>> database and update it?

>Yes.

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.

>> I don't need SQL (but would use it if it were already provided).
>> How about with dBase/FoxBase?
>
>As mentioned above, a small SQL server is included. dBase/Foxbase
>files are supported as well if memory serves.

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.

>> Or should I plan on either purchasing a 3rd-party addin or
>> using plain text files?

>Actually, MS supplies a driver that can talk to CSV and
>tab-separated files as well -- though as I recall, those are
>supported primarily (exclusively?) via ADO, not ODBC or DAO (the
>two database connection technologies for which MFC has the most
>direct support).

But still available. In spite of the overhead involved, Ye Olde
Plain ASCII Text File has one real advantage: one can generally
repair any damage with a text editor.

--snip--
>> 3) Would this job be much simpler if I switched to MSVB.NET?
--snip--
>I don't see a whole lot of difference here -- VC++ database views
>are laid out as dialogs, roughly on the same general order as VB
>forms. It's entirely possible to write a really simple database
>viewer with VC++ without writing a single line of actual code. If
>you want to support updating of the database, you have to write a
>little, but it's still truly trivial.

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>

> ... Of course, to do much with
>the data except pipe it out from a database to a form, you'll
>probably have to write some code -- whether that's harder or easier
>than with VB will depend on both your background and what you need
>to do. While VB has some good points, I mostly find it frustrating,
>but that's me; for you, the opposite may be true.

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.

On the other hand, in my ongoing browse-the-'web effort I ran across
a couple fo control attributed called 'anchor' and 'docking' and an
object called a Panel that might make it _much_ easier to lay out my
data entry forms and to modify them later. (All I have to do now is
figure out how to add .NET controls onto my forms instead of MFC
controls.)

>> At this point in the project I could switch to VB if it looked
>> to be a better choice.
--snip--
>To me, the obvious alternative would be something specifically for
>developing databases, such as FoxPro or the developer's edition of
>Access (which can also produce more or less standalone programs).

Ah. Thanks for reminding me of these. FoxPro would involve some
learning, but Access is a possibility.


Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
Munged E-mail: frank uscore mckenney ayut minds pring dawt cahm (y'all)
--
"War is God's way of teaching Americans geography"
-- Ambrose Bierce
--
.