Re: MSVC++ app type choice, form design questions
- From: Frnak McKenney <frnak@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 21 Apr 2005 19:14:45 GMT
On Sat, 9 Apr 2005 18:44:45 -0600, Jerry Coffin <jcoffin@xxxxxxxxx> wrote:
> 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.
In this case the summary doesn't relate well to the Xes or the Ys,
so I'm planning on a set of identically-sized forms that appear or
disappear as required.
>> 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
At the risk of showing some grey in my whiskers <grin> I'll say that
I do recall trying to get reports squished into a constant-width
132-character format, but I'm not that ambitious (or masochistic!).
The pencil-and-paper stuff is so I have something to work with as I
lay the screens out -- makes it harder to forget things.
> ... 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.
True enough. Are you aware of any format that conveys that kind of
"conditional" information? For my needs it wouldn't have to be a
specific piece of software, could just be some kind of notation.
> Given the ease with which forms can be rearranged, I'd tend more
> toward the XP style of development
Can't. _I'm_ developing on MSWin2K. ("Thassa _joke_, suhn!")
> ... -- 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...
As you say, it's not worth spending days on, but a quick sketch is
often handy to refresh one's memory. I use a medium that is highly
customizable, provides a handy annotation feature, and I don't need
to worry about it not displaying correctly when viewd using Acrobat
8.9. This "paper" stuff is amazing! <grin>
As for the recordkeeping, I think I'm going to start with something
pure ASCII (e.g. CSV) and see what performance looks like. As long
as I keep the interface to the data access reasonably well
walled-off from rest of the app I should be able to change it later.
> 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...)
The first couple of times through VC++.NET I created VS Projects
based on MFC. Then I discovered that much further down below the
"MFC" project (scroll, scroll, ...) was a Windows Forms project
type, and basing my projects on _that_ has made a _big_ difference.
(My Controls Toolbox even has color!).
So far the most painful limitation in VStudio I've hit is the
difficulty in renaming things. I laid out a moderately complex form
but accidentally drew it for the wrong class; what the heck, I'll
just rename everything, right? Wrong -- you have to do a full
search-and-replace across all the project files (&deity help you if
there's any name overlap), and _then_ close down VS.NET, manually
rename the files, and restart VS.NET.
Maybe it's just me, but I often find a need to rename things to gain
a consistency whose need wasn't initially obvious. Since VS.NET
doesn't _really_ support this, the workaround adds a new potential
source of errors... and I have enough problems of my _own_ making
not to want to offer Murphy any unnecessary assistance. <grin?>
Oh, well. There was ".NET" and now ".NET 2003", with ".NET 2005" on
the way. The upgrade should hit the store shelves about two months
after this project finishes. <grin>
At any rate, thanks again for the help. I'm off to install a CD-RW
drive on the MSWin2K machine so I can try scripting the "burn"
Frank McKenney, McKenney Associates
Richmond, Virginia / (804) 320-4887
Munged E-mail: frank uscore mckenney ayut minds pring dawt cahm (y'all)
"Provide me with ships or proper sails for the celestial atmosphere
and there will be men there, too, who do not fear the appalling
distance" -- Johannes Kepler
- Re: MSVC++ app type choice, form design questions
- From: Jerry Coffin
- Re: MSVC++ app type choice, form design questions
- Prev by Date: Re: Help with RPC.
- Next by Date: Re: Give the Focus to my application
- Previous by thread: Re: MSVC++ app type choice, form design questions
- Next by thread: Re: MSVC++ app type choice, form design questions