Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Suggestions appreciated: structuring program
1 view
Skip to first unread message
Bruce Varley
Jan 28, 2012, 8:49:52 PM1/28/12
to
Hi, Just after a bit of advice on structuring a program (not homework).
This is an old process simulator that I'm porting from DOS to Win32 (MFC).
The core consists of a big loop that solves DEs inter alia, and outputs to
the screen as it goes. That works better than doing all the computation
first, then displaying it all at the end, because on a long run (up to a
minute if the problem is big) you can see how things are going and stop if
you want. The old version was just a loop in main(), and I can replicate
this on the new platform, presumably the loop would be in the application
initialisation. ie the 'initialisation' would be the whole thing.
That seems a bit crude. Any suggestion on how hte pros would handle the
situation?
This is an old process simulator that I'm porting from DOS to Win32 (MFC).
The core consists of a big loop that solves DEs inter alia, and outputs to
the screen as it goes. That works better than doing all the computation
first, then displaying it all at the end, because on a long run (up to a
minute if the problem is big) you can see how things are going and stop if
you want. The old version was just a loop in main(), and I can replicate
this on the new platform, presumably the loop would be in the application
initialisation. ie the 'initialisation' would be the whole thing.
That seems a bit crude. Any suggestion on how hte pros would handle the
situation?
![ScottMcP [MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjUbK0hEHiPmoI3ana-MaePcSwNHy6hEF_fpc1cbAKj4gE9-Xw=s40-c)
ScottMcP [MVP]
Jan 28, 2012, 11:55:59 PM1/28/12
to
(i.e., like a DOS screen) or a GUI. There wouldn't be much point in
using MFC if you are not planning a GUI.
You have to avoid lengthy loops in a GUI, since the GUI ignores user
input for the duration of the loop. Possible solutions to this are a
timer, so you do a bit of calculation then display and return to the
message pump, or a worker thread, so the thread can do the calculation
without blocking the GUI.
Bruce Varley
Jan 29, 2012, 1:11:02 AM1/29/12
to
"ScottMcP [MVP]" <scot...@mvps.org> wrote in message
news:0b537a39-c37a-4b96...@s9g2000vbc.googlegroups.com...
On Jan 28, 8:49 pm, "Bruce Varley" <b...@NoSpam.com> wrote:
> Hi, Just after a bit of advice on structuring a program (not homework).
> This is an old process simulator that I'm porting from DOS to Win32 (MFC).
> The core consists of a big loop that solves DEs inter alia, and outputs to
> the screen as it goes. That works better than doing all the computation
> first, then displaying it all at the end, because on a long run (up to a
> minute if the problem is big) you can see how things are going and stop if
> you want. The old version was just a loop in main(), and I can replicate
> this on the new platform, presumably the loop would be in the application
> initialisation. ie the 'initialisation' would be the whole thing.
>
> That seems a bit crude. Any suggestion on how hte pros would handle the
> situation?
You haven't said whether you intend to build it as a console program
(i.e., like a DOS screen) or a GUI. There wouldn't be much point in
using MFC if you are not planning a GUI.
It will be a GUI.
> Hi, Just after a bit of advice on structuring a program (not homework).
> This is an old process simulator that I'm porting from DOS to Win32 (MFC).
> The core consists of a big loop that solves DEs inter alia, and outputs to
> the screen as it goes. That works better than doing all the computation
> first, then displaying it all at the end, because on a long run (up to a
> minute if the problem is big) you can see how things are going and stop if
> you want. The old version was just a loop in main(), and I can replicate
> this on the new platform, presumably the loop would be in the application
> initialisation. ie the 'initialisation' would be the whole thing.
>
> That seems a bit crude. Any suggestion on how hte pros would handle the
> situation?
You haven't said whether you intend to build it as a console program
(i.e., like a DOS screen) or a GUI. There wouldn't be much point in
using MFC if you are not planning a GUI.
Charlie Gibbs
Jan 29, 2012, 1:34:56 PM1/29/12
to
In article
<0b537a39-c37a-4b96...@s9g2000vbc.googlegroups.com>,
procedure have user actions set flags or variables according
to what they want to do, and check in the main loop to see
whether you should do something special as a result.
while (main loop) {
while (PeekMessage (&msg, NULL, 0, 0, PM_REMOVE)) {
TranslateMessage (&msg);
DispatchMessage (&msg);
}
if (the user clicked something) {
/* take appropriate action */
}
/* remainder of main loop logic follows... */
}
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
<0b537a39-c37a-4b96...@s9g2000vbc.googlegroups.com>,
scot...@mvps.org (ScottMcP [MVP]) writes:
> You have to avoid lengthy loops in a GUI, since the GUI ignores user
> input for the duration of the loop. Possible solutions to this are a
> timer, so you do a bit of calculation then display and return to the
> message pump, or a worker thread, so the thread can do the calculation
> without blocking the GUI.
Pump messages at the start of your main loop. In your window
> You have to avoid lengthy loops in a GUI, since the GUI ignores user
> input for the duration of the loop. Possible solutions to this are a
> timer, so you do a bit of calculation then display and return to the
> message pump, or a worker thread, so the thread can do the calculation
> without blocking the GUI.
procedure have user actions set flags or variables according
to what they want to do, and check in the main loop to see
whether you should do something special as a result.
while (main loop) {
while (PeekMessage (&msg, NULL, 0, 0, PM_REMOVE)) {
TranslateMessage (&msg);
DispatchMessage (&msg);
}
if (the user clicked something) {
/* take appropriate action */
}
/* remainder of main loop logic follows... */
}
--
/~\ cgi...@kltpzyxm.invalid (Charlie Gibbs)
\ / I'm really at ac.dekanfrus if you read it the right way.
X Top-posted messages will probably be ignored. See RFC1855.
/ \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
Ulrich Eckhardt
Jan 30, 2012, 3:33:00 AM1/30/12
to
Am 29.01.2012 02:49, schrieb Bruce Varley:
> Hi, Just after a bit of advice on structuring a program (not homework).
> This is an old process simulator that I'm porting from DOS to Win32 (MFC).
> The core consists of a big loop that solves DEs inter alia, and outputs to
> the screen as it goes. That works better than doing all the computation
> first, then displaying it all at the end, because on a long run (up to a
> minute if the problem is big) you can see how things are going and stop if
> you want.
In other words, even while computing stuff the program remains
> Hi, Just after a bit of advice on structuring a program (not homework).
> This is an old process simulator that I'm porting from DOS to Win32 (MFC).
> The core consists of a big loop that solves DEs inter alia, and outputs to
> the screen as it goes. That works better than doing all the computation
> first, then displaying it all at the end, because on a long run (up to a
> minute if the problem is big) you can see how things are going and stop if
> you want.
"responsive", both in the sense of input and output.
> The old version was just a loop in main(), and I can replicate
> this on the new platform, presumably the loop would be in the application
> initialisation. ie the 'initialisation' would be the whole thing.
>
> That seems a bit crude.
complete. This has two consequences:
1. Your application will start with a delay of a minute. Experience
shows that after ten seconds without response, users will just try to
start the application again.
2. You can't input parameters via the GUI, because at the time you get a
UI, all computations are already done.
I don't think that doing things in the initialization is the way to go.
The way I imagine this is that the UI starts up and allows the user to
input parameters and then to start the simulation. The simulation is
running parallel to the UI, so new results are regularly displayed. This
can either be done with a timer function (see SetTimer/KillTimer) or a
separate worker thread. If you're not familiar with multithreading, go
for the timer, although multithreading would give better results and
allow making better use of multiple CPUs.
Good luck!
Uli
0 new messages