I think the point Tony was making was the splitting of the program logic from the actual screen formatting. One of the most arduous tasks in converting to a GUI is the splitting of the screen layout (print statements) from the business logic in programs. If your programs have the somewhat typical [EMAIL PROTECTED] SOMETHING WITH INPUT format, the PRINT@ part has to be removed as it will be replaced by the GUI. Applications that have some type of screen processor are way ahead of the game. In that scenario, your code is mostly logic and much easier to link a GUI.
You do bring up a valid point regarding event driven apps with the concept of submitting an entire form. IMO, that depends on the platform and design choices made by the developer. For example, using Redback with ASP or ASP. Net, you can pretty much mimic the field by field validations and processing of CUI programs (one of the greatest features of .Net is the auto postback). Of course there are performance considerations/penalties for doing it but you can do it. On the flip side, you could also take all the input and submit it to a server process once. More efficient but trade-offs in functionality. Mike R. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Saturday, April 17, 2004 8:18 PM To: [EMAIL PROTECTED] Subject: Re: GUI from Mv code Re: Crystal Reports In a message dated 4/17/2004 4:16:06 PM Pacific Daylight Time, [EMAIL PROTECTED] writes: > A key factor that makes CUI non-portable > to GUI is the embedded Input and Print statements in the code. I respectfully disagree that this is key. After all event oriented apps also have input statements I think you mean the key factor is that the programs are not event oriented. That is, on a typical GUI form I can click and fill in any field in any order, and then I submit the entire form. In a typical mv app, most programmers would write it so the inputs happen in a definite order and there is no way to change that order, on the fly. If programs were rewriten so that the inputs were all seperated from each other logically, and could be entered in any order. (Tab forward, tab back between fields, or point and click since mouse clicks are captured by accuterm and wintegrate among others). Then some of the validation (two field interactions) should be relegated to the On.SUBMIT part of the program, etc. If we could code in this fashion, then any app can be GUIized with less effort. Will -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
