![]() |
|
Published 1997-12-01 Printer-friendly version
Some months ago I wrote to a reviewer of a CWIC competitor that CWIC would already do all the things that this other product promised for the future. CWIC was beta 1 at the time and I noted in that message that CWIC beta 1 could easily have been a gold release from another well known software vendor.
Well, CWIC has just gone gold and the already substantial technological gap between CWIC and its erstwhile competitors has only increased.
In the final release, tabs appear as tabs and help links are supported.
Wow.
As I said at DevCon, "If you can do it in CW, you can do it in CWIC." And 95 percent or more of your app will function exactly as expected with no further intervention. The remainder is handled by modifying the default event handling to fit the specific needs of the control.
One of the very few things that you cannot do on the Web that you can do in Windows is have multiple pages (windows) visible simultaneously. This, however, is a limitation of the Web, not CWIC. (Actually, you can do even this, but that involves starting another instance of the user's browser, and its efficacy depends on assuming that the user is not running her/his browser full-screen. The latter is not a safe assumption. So, let's not pursue this now.)
In fact, the vast majority of issues you will face in Web-enabling your applications are aesthetic, not functional. Let's examine some cases.
The other major functionality that does not exist in CWIC is drop down menus. At least at this time drop down menus that can also call a procedure do not exist. So, by default, CWIC will create an HTML representation of your menu with the pulldowns dropped and spread.
If your Frame procedure does not contain a lot of menu items, the resulting HTML representation, while not exactly beautiful, is functional:

But the situation changes when your Frame contains 50 or 60 items. For example, this Windows main frame:

becomes:

Not only is this not very attractive, it is not very functional. It is not functional because no one would realistically expect a user to actually employ this menu without dire threats to continued employment.
However, CWIC allows us to move the hyperlinks created from menu items to the left side of the created page. From the Global button, select Extensions ... Internet Application Extension ... press the Windows Components button ... click the Menu tab ... drop the list next to Alignment and select Left of Window. The result:

is more attractive (less unattractive?) and much more useable. You can make this Frame more attractive by placing an image or dynamic HTML on the right (this is what Ray Creighton does on his site, http://sablesoft.brisnet.org.au/) by placing the appropriate HTML code in the Internet, after generating HTML for component embed for the ClientArea. For example,
Target.Writeln('<<img src="/vsm_bee.gif" border=0>')
(The double left angle is required, as it has been for so long in Clarion, and this is documented. Small menus, such as Figure 1 also benefit from this treatment.)
At DevCon, Bob Foreman showed another strategy for dealing with menus containing a limited number of items. Bob removed his Menu entirely, placed images on the Toolbar buttons and used only the Toolbar in the Web-enabled application. The result looks better than anything I've seen, including most HTML pages. I have tried to re-create, with less than total success, what Bob demonstrated and you can see the result at http://www.par2.com.
The point? CWIC will indeed convert your Menu and Frame procedures. But because of the limitations of HTML, you will want to break your applications down into smaller units. These smaller units can then be accessed with the default types of menus (with or without graphic enhancement), an HTML page or Bob Foreman's Toolbar technique. But, one way or another, you will, as I said in my first article on CWIC, have to rethink your applications.
In my last examination of CWIC, I noted that the biggest problem I had in Web-enabling my applications was that my data validation code did not operate, nor did my other embedded source.
The reason for this was not a deficiency in CWIC, but the nature of HTML. HTML pages only post events on Get or Submit methods, and these methods are only called by buttons. That is, events are processed by the browser.
While JavaScript can implement limited event handling, it is not what we are used to and it is not sufficient for our purposes.
This is no longer the case. As Jim DeFabia so accurately states, the CWIC team could not wait for the dynamic HTML specification to be completed. So, they did it themselves.
You can now choose to let the browser handle events or select the type of event handling you want on a control-by-control basis: a Partial or Complete Page Refresh.
You have the choice of doing a full page refresh or a partial page refresh as each control is Accepted. On the Procedure Properties windows, press the Internet Options button. Click the Controls tabs and select the control whose behavior you want to modify. Press the Properties button and click the Events tab. Select the event you want to generate, press Properties and override the event handler.
In the overwhelming majority of cases, a Partial Page Refresh is what you want. This option will update Java controls, such as entry fields, but not Prompts and string literals. Therefore, if you have data validation code behind a control, a Partial Refresh will activate it, just as in Windows.
Suppose you have a lookup on control Accept. In Windows, if the user makes no entry, nothing happens until they press the Ok button. But, if an entry is made, it is validated. With a Partial Refresh on the control, your Web application will behave the same way.
So far, I have found only one case in which a Full Page Refresh seems to be required. When I place a locator and its prompt on a browse and do a Partial Refresh on a tab change, the prompt and locator field will not change.
This is now the greatest "conversion" issue.
For example,

in Netscape 3.01 becomes:

Overall, not too bad. You will notice some movement of the controls to the right. But it is minor and, on the whole, the page does a good job of representing the original window.
Now look at what happens in Internet Explorer:

Major yuck! Controls are actually falling off the right side of the page.
It is no secret that different browsers format pages differently. This is one of the great strengths of the Web: the content provider does not need to be concerned with the end user's hardware. An HTML page produced on a Sparc Station can be read on a Mac, Unix box or WinTel machine. But this is ridiculous!
Are we totally at the mercy of how the browser "decides" to reformat our windows?
Well, actually, no we aren't. On the original window, you will notice, I used Group boxes to visually delineate blocks of related data entry fields. These fields do not form a Group in the dictionary; this is strictly aesthetic. We all do this.
However, if you move the fields into the Group box (on the window only -- a simple matter of moving the End statement -- not in the dictionary), all is much better:

What is happening is this: CWIC formats an HTML table and places your controls into that table. By placing your controls inside a Group box, it is the box (and you obviously do not have to have the Boxed attribute on) placed inside the table, not the individual controls. (My sincerest thanks to Gavin Halliday for this suggestion.)
As I said: If you can do it in CW, you can do it in CWIC, and 95 percent or more of your app will function exactly as expected with no further work. It occasionally takes a few extra mouse clicks, but that is insignificant compared to the ability to transfer everything you already know how to do to an entirely new medium.
I also remain convinced that we need to learn at least basic HTML. Bob Foreman's menu technique shows just how far a little knowledge, mixed with creativity, can go.
Copyright © 1999-2009 by CoveComm Inc. All Rights Reserved. Reproduction in any form without the express written consent of CoveComm Inc., except as described in the subscription agreement, is prohibited.
Clarion Magazine ISSN 1718-9942
One year: $169
(includes all back issues since '99)
Renewals from $119
Two years: $269
Renewals from $219