1. more info on ARF020
- Posted by gwalters at sc.rr.com
Jul 26, 2001
This is a multi-part message in MIME format.
------=_NextPart_000_006D_01C115BC.9565DB80
charset="Windows-1252"
If you drag the screen then all the input fields are sunken and this =
will also stop the looping until you move the mouse over the =
min,max,kill area again.
..confused george
------=_NextPart_000_006D_01C115BC.9565DB80
charset="Windows-1252"
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3105.105" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2>If you drag the screen then all the input fields are =
sunken=20
and this will also stop the looping until you move the mouse over the=20
min,max,kill area again.</FONT></DIV>
<DIV> </DIV>
------=_NextPart_000_006D_01C115BC.9565DB80--
2. Re: more info on ARF020
- Posted by irvm at ellijay.com
Jul 26, 2001
On Thursday 26 July 2001 10:20, gwalters at sc.rr.com wrote:
> If you drag the screen then all the input fields are sunken and this will
> also stop the looping until you move the mouse over the min,max,kill area
> again.
Mike's reply is correct, you are in effect calling onPaint recursively,
since every time the window is repainted, it calls the onPaint routine,
which repaints the window and calls the onPaint routine......ad infinitum.
I need to ask - why aren't you using Judith's IDE? It's better than
Delphi - I use them both. It will also save you a great deal of time,
since you can visually lay out your screens. Also, there won't be
any need to tinker with windows calls like the one mentioned above.
Once you've dropped some controls on the window, you just click
and run, all the low-level stuff is taken care of.
Regards,
Irv
3. Re: more info on ARF020
- Posted by gwalters at sc.rr.com
Jul 26, 2001
----- Original Message -----
From: <irvm at ellijay.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: more info on ARF020
>
>
> On Thursday 26 July 2001 10:20, gwalters at sc.rr.com wrote:
>
> > If you drag the screen then all the input fields are sunken and this
will
> > also stop the looping until you move the mouse over the min,max,kill
area
> > again.
>
> Mike's reply is correct, you are in effect calling onPaint recursively,
> since every time the window is repainted, it calls the onPaint routine,
> which repaints the window and calls the onPaint routine......ad infinitum.
>
> I need to ask - why aren't you using Judith's IDE? It's better than
> Delphi - I use them both. It will also save you a great deal of time,
> since you can visually lay out your screens. Also, there won't be
> any need to tinker with windows calls like the one mentioned above.
> Once you've dropped some controls on the window, you just click
> and run, all the low-level stuff is taken care of.
All the screens are already layed out (approx 70 of them) in another
environment and I'm trying to find how this new stuff works so I can then
'convert' the screens to some type of sequence so they don't have to be
constructed one by one...
There's a lot I don't understand here but slowly, bit by bit, I think i'm
beginning to see the process...
..george
>
> Regards,
> Irv
>
>
>
>
>
4. Re: more info on ARF020
- Posted by irvm at ellijay.com
Jul 26, 2001
On Thursday 26 July 2001 12:11, gwalters at sc.rr.com wrote:
> All the screens are already layed out (approx 70 of them) in another
> environment and I'm trying to find how this new stuff works so I can then
> 'convert' the screens to some type of sequence so they don't have to be
> constructed one by one...
I expected you to say that. I've often wished I could
do something similar. The truth is, it is a 'bad idea'.
One of the common misconceptions is that a procedural program
can be easily translated into an event-driven windows program,
and function properly. This is generally not the case. If you try to
do it anyway, you lose out to those who accept the differences,
and write programs that *do* use event-driven features to
their advantage.
People who use Windows (or xWindows, or Mac) programs
expect, for example, to be able to move on the fly from one task
to another as needed. Example: someone is entering invoices
into the system. No customer record has been created for the next
invoice. Windows users expect to be able to pop up a screen, enter the
new customer data, and then contine where they left off on the
invoice entry screen, without closing the program or creating an
error condition. Or, perhaps they need to pop up another customer's
account to look up some info, without cancelling the work they are
currently doing.
A second concept that makes translation impractical is that of
presenting only what information a user needs at the moment.
Take your ARF020 data entry screen, for example.
It would be much easier to use if the customer name, address,
etc were presented on the screen, and below that three tab items,
each tab of which showed a category of items, only a click away.
Just as an example;
Under Preferences tab:
Salesman
Tax info
Default Shipping info, etc.
Under Terms tab:
Cust. group
Price level
Credit limit
Pmt terms, etc
Under Account Status tab:
Last invoice date, amt
Last pmt date, amt
YTD sales, etc....
You can see that, by categorizing the displayed data, and presenting
only that which the user is concerned with at the moment, you gain
in several ways:
1. Your program is easier to use.
2. Your users are less likely to modify something they didn't intend to
modify, and you don't have to validate entries that aren't accessible.
3. You have room on the screen for more informative text, which
again cuts down on errors, as well as calls for help.
4. Your program looks more professional.
BTW, my version would probaby have user-level protection on
the terms tab, so that only the acctg mgr could change a customer's
discount, etc.
Now, consider this: It would take about 30 minutes to lay out the
screen as described above, with tab items, etc. The result would
be a program with a more professional look and feel, and that will
outweigh the small amount of time invested in designing the new
screen. (It's also likely that the errors introduced in porting the existing
screens will take more time to track down than it would take
to design new screens in the first place;)
Regards,
Irv
5. Re: more info on ARF020
- Posted by gwalters at sc.rr.com
Jul 26, 2001
I agree with you in principle, but my knowledge base at present is far from
that level. I'm in a learning mode at this point. I will say however that
even though windows is event driven and not procedural, an accounting
application is procedural by its very nature. So I beleive a good deal of
effort in windows programming would be to defeat its event nature to
preserve those items in accounting that must be sequential one after the
other.
...george
----- Original Message -----
From: <irvm at ellijay.com>
To: "EUforum" <EUforum at topica.com>
Subject: Re: more info on ARF020
>
>
> On Thursday 26 July 2001 12:11, gwalters at sc.rr.com wrote:
>
> > All the screens are already layed out (approx 70 of them) in another
> > environment and I'm trying to find how this new stuff works so I can
then
> > 'convert' the screens to some type of sequence so they don't have to be
> > constructed one by one...
>
> I expected you to say that. I've often wished I could
> do something similar. The truth is, it is a 'bad idea'.
>
> One of the common misconceptions is that a procedural program
> can be easily translated into an event-driven windows program,
> and function properly. This is generally not the case. If you try to
> do it anyway, you lose out to those who accept the differences,
> and write programs that *do* use event-driven features to
> their advantage.
>
> People who use Windows (or xWindows, or Mac) programs
> expect, for example, to be able to move on the fly from one task
> to another as needed. Example: someone is entering invoices
> into the system. No customer record has been created for the next
> invoice. Windows users expect to be able to pop up a screen, enter the
> new customer data, and then contine where they left off on the
> invoice entry screen, without closing the program or creating an
> error condition. Or, perhaps they need to pop up another customer's
> account to look up some info, without cancelling the work they are
> currently doing.
>
> A second concept that makes translation impractical is that of
> presenting only what information a user needs at the moment.
>
> Take your ARF020 data entry screen, for example.
> It would be much easier to use if the customer name, address,
> etc were presented on the screen, and below that three tab items,
> each tab of which showed a category of items, only a click away.
> Just as an example;
>
> Under Preferences tab:
> Salesman
> Tax info
> Default Shipping info, etc.
>
> Under Terms tab:
> Cust. group
> Price level
> Credit limit
> Pmt terms, etc
>
> Under Account Status tab:
> Last invoice date, amt
> Last pmt date, amt
> YTD sales, etc....
>
> You can see that, by categorizing the displayed data, and presenting
> only that which the user is concerned with at the moment, you gain
> in several ways:
>
> 1. Your program is easier to use.
> 2. Your users are less likely to modify something they didn't intend to
> modify, and you don't have to validate entries that aren't accessible.
> 3. You have room on the screen for more informative text, which
> again cuts down on errors, as well as calls for help.
> 4. Your program looks more professional.
>
> BTW, my version would probaby have user-level protection on
> the terms tab, so that only the acctg mgr could change a customer's
> discount, etc.
>
> Now, consider this: It would take about 30 minutes to lay out the
> screen as described above, with tab items, etc. The result would
> be a program with a more professional look and feel, and that will
> outweigh the small amount of time invested in designing the new
> screen. (It's also likely that the errors introduced in porting the
existing
> screens will take more time to track down than it would take
> to design new screens in the first place;)
>
> Regards,
> Irv
>
>
>
>
>
6. Re: more info on ARF020
- Posted by irvm at ellijay.com
Jul 26, 2001
On Thursday 26 July 2001 15:06, gwalters at sc.rr.com wrote:
> I agree with you in principle, but my knowledge base at present is far from
> that level. I'm in a learning mode at this point. I will say however that
> even though windows is event driven and not procedural, an accounting
> application is procedural by its very nature. So I beleive a good deal of
> effort in windows programming would be to defeat its event nature to
> preserve those items in accounting that must be sequential one after the
> other.
You are right in the sense that you must carefully separate certain
procedural aspects of some programs from the user interface.
In an accounting program, some things just must be done in the
proper sequence. However, there's no problem isolating these, nor
in implementing various checks to monitor the current status,
and warn the user if certain things are being done out of order.
As far as accounting being procedural, it is only so at certain times.
Most of the time, your program probably bounces from verifying
a customer's balance, to entering adjustments, to running a daily
sales report, and back to adding invoices, all at the whim of the
operator(s). Only when it is decided that it's time to run statements
and close out the month is it truly procedural.
I'll send you privately an exw of your edit screen created with the IDE.
It didn't take quite 20 minutes.
Regards,
Irv
