Re: MSVC++ app type choice, form design questions
- From: Jerry Coffin <jcoffin@xxxxxxxxx>
- Date: Thu, 7 Apr 2005 23:40:42 -0600
In article <pQm5e.2431$sp3.17@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
frnak@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx says...
[ ... ]
> 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.
> 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. :-)
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).
> 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.
>
> I'd guess <grin> that full Oracle and Sybase support aren't
> bundled, but -- without purchasing any other software -- could
> I create an MSVC++ standalone app that could be installed on
> MSWin2K and MSWinXP machines that could create and update
> (say) an Access database?
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.
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).
> 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.
> 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.
>
> 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).
> Finally, there's the choice of development environment. I had
> assumed that the amount of effort required to build this app would
> be about the same whether I used MSVC++, MSVB, or something similar.
> After several hours' reading of the MSVC-related newsgroups this
> evening, I'm prompted to ask this:
>
> 3) Would this job be much simpler if I switched to MSVB.NET?
> I've seen several comments that seem to hint that at least the
> screen design portion would be much easier in VB, especially
> if my customer wants all of the screens laid out differently
> half-way through the project (don't they all? <grin>).
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. 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.
> At this point in the project I could switch to VB if it looked
> to be a better choice. I'm much less worried about the cost
> of MSVB.NET or the time to (re-)learn it than I am about using
> the best tool for the job... or at least a measurably more
> effective tool, if one exists.
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).
--
Later,
Jerry.
The universe is a figment of its own imagination.
.
- Follow-Ups:
- Re: MSVC++ app type choice, form design questions
- From: Frnak McKenney
- Re: MSVC++ app type choice, form design questions
- References:
- MSVC++ app type choice, form design questions
- From: Frnak McKenney
- MSVC++ app type choice, form design questions
- Prev by Date: Re: How to write a COM object which can be refered in C# .NET prj?
- Next by Date: Re: visual studio c++ .net 2005 and mfc?
- Previous by thread: Re: MSVC++ app type choice, form design questions
- Next by thread: Re: MSVC++ app type choice, form design questions
- Index(es):
Relevant Pages
|
