Cobol - Treeviews

Author

Treeviews

James J. Gavan

2005-02-22, 3:55 pm

Really just to advise Kellie and Michael. I've solved it, (how to
indicate what has been actioned or not actioned). Like all things GUI
not difficult once you can see a coded solution - it's finding the
solution, (from the plethora of methods), which can sometimes be
frustrating.

As images I create an Array (collection) containing two icons, Greenball
and RedBall, identified respectively as 1 and 2. First showing of the
Treeview you want all to appear as 'Unactioned' = Redball. After intimal
display any Adds, Changes or Deletes affect the display. For Add and
Change, select Greenball. Delete - well the label disappears from your
Treeview and the record is deleted from File/DB

As you create/revise the displayable Label you select the icon value 1
or 2 which gets 'attached' to your label. (Interesting point - setting
the size for your icons to 16 x 16, when creating the icon Array above,
controls how the rest of the Treeview displays; use 48 x 48 and the
whole Treeview picture EXPANDS, automatically throwing in an Horizontal
Scrollbar which you will need to use to see the 'clipped' or right side
of the Treeview).

You might recall I was experimenting with Buttons/NoButtons,
LinesAtRoot/NoLinesAtRoot, Lines/NoLines. I 'discovered' if I code
'noButtons' and use icons - then you can click on icons to expand or
contract the Treeview. The only time it appears to come 'unstuck' is if
the user contracts the Treeview to show just the Root Level. (When I do
my initial display I expand the Root to show the list of Level 1's).

The only outstanding feature I have to resolve, not GUIs but program
logic, is how to indicate the Level above should appear as a GreenBall
when all its 'children' have Greenballs.

(1) - invoke ThisLevelObject "getAncestor" returning ParentLevelObject

(2) - invoke ParentLevelObject "getID" returning IconID - if it shows
already Greenball - no further action; otherwise :-

(3) - invoke ParentLevelObject "children" returning
ParentLevelOrderedCollection

(4) - do a callback/iterator against the ParentLevelOrderedCollection
testing each element (Child Label), for its IconID - if they all show
Greenball then the Parent Level label can be changed to show a Greenball

(5) - depending upon how many Levels you have, will need to work upwards
through the hierarchy to see if any other ParentLevels have to be
changed to Greenball. (e.g. this Level 2 has now be changed to a
Greenball and Level 1 has a RedBall - check the Level 1 to see if it
should be changed to a Greenball - this is a repeat of Steps 1 through 4
above).

(6) Deletes - well they are 'destroyed' - but they *might* affect the
outcome. Assume five Level 3 labels - four are Greenballs and the fifth,
which you are deleting, is a Redball. Got to use the routines above to
see if the Level 2 can now be changed to a Greenball.

Not at all difficult using the methods provided - just have to get my
logic correct.

Jimmy, Calgary AB

Kellie Fitton

2005-02-22, 8:55 pm

Hi Jimmy,

it looks like the TreeView window you have created will show your true
colour. ;--))

well, I must remind you though, Sophisticated cobol programmers like
Kellie Fitton
do not use the so-called OO. Why? I am glad you asked --- Its
verbose, bloated,
wordy, not a practical programming model, have a major problem with
prolixity, and
no clear or identifiable benefits whatsoever when compared to practical
Cobol.
for me though, using direct win32 API's is a result oriented approach,
without the
unnecessary and superfluous steps. Hope your TreeView bear some
fruits.

Regards, Kellie.

James J. Gavan

2005-02-22, 8:55 pm

Kellie Fitton wrote:
> Hi Jimmy,
>
> it looks like the TreeView window you have created will show your true
> colour. ;--))
>
> well, I must remind you though, Sophisticated cobol programmers like
> Kellie Fitton
> do not use the so-called OO. Why? I am glad you asked --- Its
> verbose, bloated,
> wordy, not a practical programming model, have a major problem with
> prolixity, and
> no clear or identifiable benefits whatsoever when compared to practical
> Cobol.
> for me though, using direct win32 API's is a result oriented approach,
> without the
> unnecessary and superfluous steps. Hope your TreeView bear some
> fruits.
>
> Regards, Kellie.
>
Kellie,

Glad you wrote that because I was itching to ask what made you take the
API approach. 'Prolixity' WOW ! Verbose, bloated, wordy or prolixity -
according to my Thesaurus - all kinda the same. Now who is being verbose
? :-)

Feisty little Californian aren't you :-)

Absolutely no harm in you taking your approach, using APIs; same sort of
thinking as Michael. Not knowing them, (APIs) have you had a dabble at
doing stuff for the Web - I'm not even aware - Can you do it with APIs ?

But caution - you are young enough to be flexible. So even having
decided on the API route always keep your mind open. Now here's a
thought - there are primarily three of us here that have done any OO
COBOL promoting - it just so happens all three of us each have 40 years
plus in this racket. Pete and Donald in programming and yours truly as a
systems analyst, switching to COBOL in 1980. Now ask yourself the
question, 'Why would three old farts favour OO COBOL ?' Just to add to
that, Richard (also an old fart, but some 10-15 years younger than me),
has recently posted some OO code, but I haven't had time to assimilate
it - concentrating on my Treeview thinggy.

Now how did you arrive at your conclusion about OO COBOL. Was it looking
at the Micro Focus examples ? Remember, remember, those are demos
illustrating features - virtually impossible to cover every feature and
to 'newbies' it wouldn't have helped if they had taken shortcuts - would
have generated just further confusion. Starting with VISOC, the
predecessor to Net Express, I was 'the newbie' and so frustrated and
miserable working it out on my own that I came very close to throwing in
the towel on two occasions. (But the stubborn 'Irish' in me persisted).

As a plug, I'm guessing you have missed the significance of one very
important element of OO - Instances. Richard made comment on it in his
latest messages. That is an extremely POWERFUL feature allowing for
umpteen uses of code - REUSE.

Not immediately because I'm still fine tuning - I could send you a copy
of my Cheese Treeview application. It is a self-contained application
(1) Business Logic (2) Classes for handling COBOL files (3) A template
class for creating the five dialogs as five instances. (Haven't used it
in this 'test run' but I could have substituted some of my SQL
techniques to replace COBOL files). Compile it and run it through the
Animator - you might get some surprises, although it wont necessarily
make you a convert to OO - that's because you Scots are also bloody
stubborn !

Let me know if you would be interested in getting a copy. I'm using N/E
3.1 - so there should be no problems at your end.

You are young, stay fresh, and particularly so, ENJOY the career you
have chosen. Be on the lookout for new techniques - and every success in
your future career.

Jimmy

Michael Mattias

2005-02-22, 8:55 pm

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:VsNSd.474145$6l.428752@pd7tw2no...
> Absolutely no harm in you taking your approach, using APIs; same sort of
> thinking as Michael.

Yeah, but Michael uses API's not because of any prejudices against O-O... he
does it because that was the sum total of his "choices" using his current
compiler....(Which is a BASIC language compiler.. but of course, all that
API knowledge can be applied transparently to any other language compiler.)

MCM

James J. Gavan

2005-02-22, 8:55 pm

Michael Mattias wrote:
> "James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
> news:VsNSd.474145$6l.428752@pd7tw2no...
>
>
>
> Yeah, but Michael uses API's not because of any prejudices against O-O... he
> does it because that was the sum total of his "choices" using his current
> compiler....(Which is a BASIC language compiler.. but of course, all that
> API knowledge can be applied transparently to any other language compiler.)
>

True - but it is accumulating that knowledge. It would have helped if
Microsoft had produced a 'Dick and Jane' book on Windows.

Why you would want to do it I don't know, but latest I've found is that
you can hang a Combo DropDownList on a Treeview. Next one I'm waiting
for is an article/screenshot on hanging a Treeview, on a Treeview, on a
Treeview......ad nauseum.

Jimmy

Pete Dashwood

2005-02-22, 8:55 pm

"Kellie Fitton" <KELLIEFITTON@YAHOO.COM> wrote in message
news:1109103985.346115.91420@o13g2000cwo.googlegroups.com...
> Hi Jimmy,
>
> it looks like the TreeView window you have created will show your true
> colour. ;--))
>
> well, I must remind you though, Sophisticated cobol programmers like
> Kellie Fitton
> do not use the so-called OO. Why? I am glad you asked --- Its
> verbose, bloated,
> wordy, not a practical programming model, have a major problem with
> prolixity, and
> no clear or identifiable benefits whatsoever when compared to practical
> Cobol.

And I thought only the old had fixed ideas on things they don't
understand... <g>.

OO programming is the single most successful paradigm (for everyone EXCEPT
COBOL) in the history of computer programming.

Saying it is not a practical programming model is like saying that
electronics should never replace steam.

There are implications in the use of OO which you haven't even considered.
It opens up the world of components, for a start...

Jimmy has written an excellent response to you Kellie and his advice is
good. Keep your mind open. Your best position is: "OO programming does not
appeal to me at this time."

I understand your fascination with the windows API; you are right, it is
immediate and direct. BUT you seem to have ignored all the points made in
this thread about it locking you in to a single OS.

And to answer Jimmy's question, NO, you would not use APIs in web
programming. (Unless you want to limit your application to running on MS
servers, and that kind of limits the field and defeats the object of using
the web in the first place.) Besides, there is no need to use the API; all
the classes you will need on the web are available through JavaScript or
Java applets and servlets. Scripting languages like ASP and JSP utilise OO
classes and components to glue the whole thing together. I can connect to a
remote database, run SQL against it, and get back a result set in three
lines of code. This is possible because under the covers it is using ActiveX
components to do the work. In this environment it is unthinkable NOT to use
OO.
Most of the stuff I am doing currently is web based, I'm using ASP (looking
at PHP) and Javascript. It would be pointless without OO and components.

So, what you are saying, Kellie, is that you will never use the web or need
to write smart web pages. (any one can write static HTML pages that get
served up like cold fish and chips; smart pages are generated on the fly,
based on events and database responses. Not only is it fun, it is
commercially rewarding as well...) That is a very short sighted view for one
at the beginning of their career.

> for me though, using direct win32 API's is a result oriented approach,
> without the
> unnecessary and superfluous steps. Hope your TreeView bear some
> fruits.
>

Fair enough. But realise you may grow...

> Regards, Kellie.
>
>

Michael Mattias

2005-02-22, 8:55 pm

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:381r3qF5ffkamU1@individual.net...
>
> OO programming is the single most successful paradigm (for everyone EXCEPT
> COBOL) in the history of computer programming....

Real Men Don't Need No Stinkin' Objects.

MCM

Kellie Fitton

2005-02-22, 8:55 pm

Hello Again,

Thanks for offering a copy of your ThreeView
program --- I prefer to create my own TreeView
version with win32 API's though. Its more
streamlined and easier to read and navigate thru
out the source code anyway. That said.

now regarding the web question, Yes. you can
use the win32 API's to create all kinds of
applications for the web, including TCP/IP
protocols, RAS services and very

web
animations as well. Currently I am learning to
develop cobol programs with 3D graphics by
using the win32 API's. I bought some nices
books from amazon.com to show me all the
tricks that I need to know about graphics.

lately I been de-bunking and "cobolizing" lots of
C, C++ examples form the web and from the
MSDN website, and I can tell it is much easier
and more practical to only use the win32 API's
functions rather than using OO programming.

Regards, Kellie.

Richard

2005-02-23, 3:55 am

> It would have helped if Microsoft had produced a 'Dick and Jane' book
on Windows.

They left it for Petzold to do. Leastways that's how I learned Windows
3.0 (after using Townsend for 2.0).

Richard

2005-02-23, 3:55 am

> Most of the stuff I am doing currently is web based, I'm using ASP
(looking
> at PHP)

It seems to me that the server side web stuff is divided into two
groups. On one side there is ASP, PHP, JSP. On the other side there
is Java srvlets, CGI, Perl and other scripts.

The first group is 'code in page': the html web pages incorporate
server side code that executes to extract data base stuff. The second
group is 'page in code': the program runs and builds the data then
writes out the html for the web page.

In many cases both of these approaches mingle the program code and the
html in ways that make then inseparable. I hate that.

> It would be pointless without OO and components.

Ah, now here is the crux of the matter. When using ASP or JSP etc the
code is buried in the web page and this means that it may need to be
duplicated if the same result is required in a different page. The
'solution' is to extract the code and make it into a component so that
it can be accessed from two or more pages.

Leastways this is how JSP solves the problem, though I think that JSP
is just a means for Java to have a 'me too' workalike for ASP and
wouldn't otherwise be used at all.

It still seems to me to be a backwards solution to a problem that
shouldn't exist in the first place.

ASP, JSP and PHP (and mod-Perl if you prefer that) are 'web page
writers' languages. The users want to design the pages and then fixup
the issue of 'how do I get the data in here'. OTOH Servlets, Perl and
so on tend to be 'programmers' languages where they extract the data
and then kludge up something to get the html out to the user.

I use templating (I may have mentioned this). To me that fits into the
middle between ASP/JSP and the usual scripting/Perl/servlets approach
(though Perl does have templating). While it runs as a typical script
it completely separates the presentation from the code. This has some
advantages. For example if you wnat that table of invoices in a usable
format then just get the program to use a different template that
outputs csv instead of html.

> and Javascript.

Javascript is client side, though it is just built into the html page
just as ASP/JSP/PHP is.

Kellie Fitton

2005-02-23, 3:55 am

Hi Pete,

Thanks for the valuable advise. Of course I like the web, its fun and
exciting. However,
the OO classes and the scripting languages that you have mentioned
above, donot really
do any thing that would be considered an impossible feat, in fact,
these classes are
sitting on top of the windows API's system or some low-level assembly
code, which is
exactly the same as the win32 API's functions. I would like to show
you an example of
C++ code for "WMI Components", which is OO programming from the MSDN
website,
it will demonstrates that this programming paradigm is inefficient with
a high overhead.
Why?, this little program is Only doing three simple things, that you
can do with cobol
and some win32 API's functions, with much less programming code.
Regards.

*>-------------------------------------------------------------------------*>
Platform SDK: Windows Management Instrumentation
*> Example: Creating a WMI Application
*> The following code example describes a complete WMI client
*> application that performs COM initialization, connects to WMI
*> on the local computer, reads some data, and cleans up.

#define _WIN32_DCOM
#include <iostream>
using namespace std;
#include <comdef.h>
#include <Wbemidl.h>
# pragma comment(lib, "wbemuuid.lib")

int main(int argc, char **argv)
{
HRESULT hres;

// Initialize COM.
hres = CoInitializeEx(0, COINIT_MULTITHREADED);
if (FAILED(hres))
{
cout << "Failed to initialize COM library. "
<< "Error code = 0x"
<< hex << hres << endl;
return 1; // Program has failed.
}

// Initialize
hres = CoInitializeSecurity(
NULL,
-1, // COM negotiates service
NULL, // Authentication services
NULL, // Reserved
RPC_C_AUTHN_LEVEL_DEFAULT, // authentication
RPC_C_IMP_LEVEL_IMPERSONATE, // Impersonation
NULL, // Authentication info
EOAC_NONE, // Additional capabilities
NULL // Reserved
);

if (FAILED(hres))
{
cout << "Failed to initialize security. "
<< "Error code = 0x"
<< hex << hres << endl;
CoUninitialize();
return 1; // Program has failed.
}

// Obtain the initial locator to Windows Management
// on a particular host computer.
IWbemLocator *pLoc = 0;

hres = CoCreateInstance(
CLSID_WbemLocator,
0,
CLSCTX_INPROC_SERVER,
IID_IWbemLocator, (LPVOID *) &pLoc);

if (FAILED(hres))
{
cout << "Failed to create IWbemLocator object. "
<< "Error code = 0x"
<< hex << hres << endl;
CoUninitialize();
return 1; // Program has failed.
}

IWbemServices *pSvc = 0;

// Connect to the root\cimv2 namespace with the
// current user and obtain pointer pSvc
// to make IWbemServices calls.

hres = pLoc->ConnectServer(

_bstr_t(L"ROOT\\CIMV2"), // WMI namespace
NULL, // User name
NULL, // User password
0, // Locale
NULL, // Security flags
0, // Authority
0, // Context object
&pSvc // IWbemServices proxy
);

if (FAILED(hres))
{
cout << "Could not connect. Error code = 0x"
<< hex << hres << endl;
pLoc->Release();
CoUninitialize();
return 1; // Program has failed.
}

cout << "Connected to ROOT\\CIMV2 WMI namespace" << endl;

// Set the IWbemServices proxy so that impersonation
// of the user (client) occurs.
hres = CoSetProxyBlanket(

pSvc, // the proxy to set
RPC_C_AUTHN_WINNT, // authentication service
RPC_C_AUTHZ_NONE, // authorization service
NULL, // Server principal name
RPC_C_AUTHN_LEVEL_CALL, // authentication level
RPC_C_IMP_LEVEL_IMPERSONATE, // impersonation level
NULL, // client identity
EOAC_NONE // proxy capabilities
);

if (FAILED(hres))
{
cout << "Could not set proxy blanket. Error code = 0x"
<< hex << hres << endl;
pSvc->Release();
pLoc->Release();
CoUninitialize();
return 1; // Program has failed.
}

// Use the IWbemServices pointer to make requests of WMI.
// Make requests here:
// For example, query for print queues that
// have more than 10 jobs
IEnumWbemClassObject* pEnumerator = NULL;
hres = pSvc->ExecQuery(
bstr_t("WQL"),
bstr_t("SELECT * Win32_PerfFormattedData_Spooler_PrintQue
ue "
"Where Name <> '_Total'"),
WBEM_FLAG_FORWARD_ONLY | WBEM_FLAG_RETURN_IMMEDIATELY,
NULL,
&pEnumerator);

if (FAILED(hres))
{
cout << "Query for print queues failed. "
<< "Error code = 0x"
<< hex << hres << endl;
pSvc->Release();
pLoc->Release();
CoUninitialize();
return 1; // Program has failed.
}
else
{
do
{
IWbemClassObject* pInstance = NULL;
ULONG dwCount = NULL;

hres = pEnumerator->Next(
WBEM_INFINITE,
1,
&pInstance,
&dwCount);

} while (hres == WBEM_S_NO_ERROR);

}

// Cleanup
// ========
pSvc->Release();
pLoc->Release();
CoUninitialize();

return 0; // Program successfully completed.
}

*>-------------------------------------------------------------------------------------*>

James J. Gavan

2005-02-23, 3:55 pm

Richard wrote:
>
> on Windows.
>
> They left it for Petzold to do. Leastways that's how I learned Windows
> 3.0 (after using Townsend for 2.0).
>
Richard,

I know your reference to Petzold - I have an early copy. I should have
been a bit more expansive. I really detest looking through MSDN - just
as I dislike on-line help files - you pick a word get some hits and then
easily get diverted to ancillary topics, and finish up with stuff
totally unrelated to your previous search.

In the case of the MSDN search engine, dependent upon the use of the
word 'Treeview' and any other search words you associate with it, you
get zillions of hits on dozens of articles - and it just never seems to
hit the right one.

As you are well aware our COBOL vendors have gotten into on-line books;
same I'm sure applies to other languages. Take GUI-ing which is, what, a
subset of APIs. Say from MS - a broad outline, then even chapters or
subsidiary books that cover one control in exhaustive detail - it's
already there but they have it spread all over the place in Knowledge
Base articles. I shouldn't have to 'discover' the significance of
changing the size of Treeview Node labels and what impact is has on what
you display - it should be there in bold black and white in a
comprehensive text on Treeviews. Same sort of thing applies to hanging
checkboxes, colouring or droplists on the Treeviews.

I like the book approach. M/F started OO with just on-line help. Now I'm
reasonably comfortable on the topic they now have an on-line book in N/E
V 4.0. ;-)

Still you can always learn more and the book is a pretty good starting
point.

Jimmy

James J. Gavan

2005-02-23, 3:55 pm

Kellie Fitton wrote:
> Hi Pete,
>
> Thanks for the valuable advise. Of course I like the web, its fun and
> exciting. However,
> the OO classes and the scripting languages that you have mentioned
> above, donot really
> do any thing that would be considered an impossible feat, in fact,
> these classes are
> sitting on top of the windows API's system or some low-level assembly
> code, which is
> exactly the same as the win32 API's functions.

Perfectly true - anything I do in OO COBOL, plus the GUIs of course,
EVENTUALLY references an API. But recall Richard said, avoid the grubby
details.

I look at your code and mumble, "Gibberish, gibberish.....". No it's
not, I'm sure it is close to doing the job. :-)

#1 - Let's backtrack on verbosity, randomly taking one of your API
entries :-

>
> _bstr_t(L"ROOT\\CIMV2"), // WMI namespace
> NULL, // User name
> NULL, // User password
> 0, // Locale
> NULL, // Security flags
> 0, // Authority
> 0, // Context object
> &pSvc // IWbemServices proxy
> );
>

Now let's backtrack on my previous message where I showed methods being
invoked to check out the colouring - this is not the whole story, but
just the ones I quoted :-

> (1) - invoke ThisLevelObject "getAncestor" returning ParentLevelObject
>
> (2) - invoke ParentLevelObject "getID" returning IconID
>
> (3) - invoke ParentLevelObject "children" returning
> ParentLevelOrderedCollection
>

OO COBOL is verbose - do a count on the above - how many sending
parameters do you see ?

I'm not going to try and blind-side you. Of course there are situations
where I supply sending parameters, not often, but some of the M/F
methods require more than one parameter, - but those three above, a
support service from M/F contain it all in the method-name.

As yet I'm not into Webbing. Are you up to a small challenge, at your
leisure. The Treeview Demo I've written has five dialogs. Just keep it
simple to one. We want to edit a cheese so it contains :-

1) Top right the 'x' for close dialog
2) An entry field for the File or DB ID - I'm using pic 9(06)
3) Entry field - 20 characters for a cheese name
4) A combo dropdown list for countries, Australia, New Zealand, England,
France etc. I identify them as pic 9(03) in file/DB
5) Two pushbuttons - OK and Cancel

Let's see your API code and then mine. (That's kinda - You show me yours
and I'll show you mine :-) ).

Now here's the 'catcher' - I will ONLY show you the code required to
generate the Cheese Dialog, display it and send events back to my Driver
program. My code will make umpteen references to pre-written code that
you wont see ! (Naturally a lot is invokes to M/F support but there are
also a lot of invokes to my own support classes).

REUSE !

Just to finish off, and back to your quoted example. Sure, if it works,
and I understood what it was doing - I'd use it, wrapping the code in an
OO method. Actually, rather like Young Kim has his API routines in
chapters, I would look for commonality, creating my own classes, say
representing his Chapter 1, Chapter 2 etc... But Webbing, not my baby,
has so many tools, scripting and Java etc., which I'm guessing are
considerably more flexible than dabbling with raw API calls. Richard has
just recently blown me away with his latest message on that topic - and
the approaches you can take.

As a point of interest - M/F's Answer Exchange, (which has a cross
section from North and some from South America, Europe, S.Africa, Asian
(India and Philippines) etc.) - quite a bit of clarification asked on
'How to' using Dialog System and 'How to' using Web features. I can't
recall the last time I saw something specifically quizzing about APIs.

Jimmy, Calgary AB

Pete Dashwood

2005-02-23, 8:55 pm

Richard,

I don't take issue with your observations, but there are a few points of
fact that may have been overlooked... see below.

"Richard" <riplin@Azonic.co.nz> wrote in message
news:1109131731.753197.196380@g14g2000cwa.googlegroups.com...
> (looking
>
> It seems to me that the server side web stuff is divided into two
> groups. On one side there is ASP, PHP, JSP. On the other side there
> is Java srvlets, CGI, Perl and other scripts.
>
That is a fair comment, but it isn't quite as rigid as that. (see below).

> The first group is 'code in page': the html web pages incorporate
> server side code that executes to extract data base stuff. The second
> group is 'page in code': the program runs and builds the data then
> writes out the html for the web page.

Hmmm... certainly ASP runs on the server, but so do the items in your second
group.
>
> In many cases both of these approaches mingle the program code and the
> html in ways that make then inseparable. I hate that.
>
Me too. But it doesn't HAVE to be like that. You CAN intermingle client side
HTML and JavaScript with ASP code but it is not a REQUIREMENT.

I have found through experience that completely separating ASP code to
BEFORE the <HTML> tag helps immensely. (It also allows non-persisting
(session duration only) cookies to be served in the Browser header, so that
state can be easily maintained without reliance on Session or Application
scope. Of course, some people don't allow cookies, but I am prepared to
'lose' those people. The cookies I am talking about are NOT stored on the
Client hard drive)

My smart pages have their ASP procedures at the start. These procedures are
written in JavaScript (within ASP delimiters, simply using JavaScript as the
language. The default is VBScript, but I have more affinity with Java than I
do with VB.)

>
> Ah, now here is the crux of the matter. When using ASP or JSP etc the
> code is buried in the web page and this means that it may need to be
> duplicated if the same result is required in a different page. The
> 'solution' is to extract the code and make it into a component so that
> it can be accessed from two or more pages.

Well, Richard, that is ONE solution. You can also use SSI from ASP and
simply include your (single copy of) source where you want it.
>
> Leastways this is how JSP solves the problem, though I think that JSP
> is just a means for Java to have a 'me too' workalike for ASP and
> wouldn't otherwise be used at all.
>
<G> You could be right...

> It still seems to me to be a backwards solution to a problem that
> shouldn't exist in the first place.
>
> ASP, JSP and PHP (and mod-Perl if you prefer that) are 'web page
> writers' languages. The users want to design the pages and then fixup
> the issue of 'how do I get the data in here'.

Yes, that is a fair description. Realise though that you can write ASP in
either VBScript or JavaScript or any other language you like - Perl, PHP,
whatever...(I'm currently experimenting with COBOL as script, just for the
Hell of it...), PROVIDED you make the appropriate Registry Script Engine
entries, ensure your language is COM compliant, and ensure the code uses
'RUNAT = server' attribute of the <SCRIPT> tag. This is possible because of
components (In this case ActiveX - impossible without OO...).

OTOH Servlets, Perl and
> so on tend to be 'programmers' languages where they extract the data
> and then kludge up something to get the html out to the user.
>
Some people do. Not me... <g>

> I use templating (I may have mentioned this). To me that fits into the
> middle between ASP/JSP and the usual scripting/Perl/servlets approach
> (though Perl does have templating). While it runs as a typical script
> it completely separates the presentation from the code. This has some
> advantages. For example if you wnat that table of invoices in a usable
> format then just get the program to use a different template that
> outputs csv instead of html.
>
Yes, I agree with that approach, Richard, and use something very similar for
CGI code. My CGI code invariably uses templates. So far, I haven't found the
need for it with ASP but it is very simple to include a template then modify
it, under ASP.

In fact, I believe ASP, properly designed, can replace CGI code completely.

>
> Javascript is client side, though it is just built into the html page

No, as I tried to describe above, it can be client or server side, depending
on where and how you write it.

> just as ASP/JSP/PHP is.

All of my ASP is server side. (I didn't know it could run client side; are
you sure about that?)The Active Server Pages engine resides on the server
and 'scans' each page before it is served up. This enables dynamic HTML to
be generated on the page or existing HTML on the page to be modified. HTML
(client side) scripts on the page can utilise ASP to replace variables, get
query strings, and so on, BEFORE the page ever reaches the client.

Half the fun of designing in this environment is working out what needs to
be server side and what needs to be client side. Avoiding 'round trips' is
very satisfying.... for example, I realised yesterday that where (in ASP
server side code) I was using Response.Redirect() to switch pages (this
involves sending an HTTP header to the Browser) I could save this trip to
the client side by using Server.Transfer() which does it immediately. I
noticed a response improvement in several pages...

I find it a very flexible and powerful solution.(Sadly, it is far removed
from COBOL and the procedural paradigm.)

Pete.

Richard

2005-02-23, 8:55 pm

>> Javascript is client side,

> No, as I tried to describe above, it can be client or server side,
depending
> on where and how you write it.

Quite right. I associate JavaScript more with being client side, either
generating the page at the client end, and/or running while the page is
being viewed, or especially while forms are being entered.

I associate VBScript with ASP, but as you say, it can be any scripting
language there is a suitable engine for.

page[color=darkred]
[color=darkred]
> (I didn't know it could run client side; are you sure about that?)

... it is just built into the html page just as ASP/JSP/PHP is built
into the html page.

No, I didn't say that ASP/JSP/PHP could be client side.

Pete Dashwood

2005-02-23, 8:55 pm

So, we can both agree that C++ can be a nightmare? <G>

Your faith in the windows API is misplaced, Kellie. I used it with Windows
3.1. When 95 was released many calls had changed. I used it occasionally
with Win 98, some of those programs failed under XP.

And you seem totally blind to the fact that Windows is not the only option
in the world.

The more separation you have from the lower levels, the more chance you have
of extending the life of your code.

But it isn't worth arguing.

I totally respect your right to do things however you want to (that doesn't
mean I don't have an opinion about it <g> )

You are doing fine and at least enjoying yourself. <G>

Pete.

"Kellie Fitton" <KELLIEFITTON@YAHOO.COM> wrote in message
news:1109131967.480922.181770@z14g2000cwz.googlegroups.com...
> Hi Pete,
>
> Thanks for the valuable advise. Of course I like the web, its fun and
> exciting. However,
> the OO classes and the scripting languages that you have mentioned
> above, donot really
> do any thing that would be considered an impossible feat, in fact,
> these classes are
> sitting on top of the windows API's system or some low-level assembly
> code, which is
> exactly the same as the win32 API's functions. I would like to show
> you an example of
> C++ code for "WMI Components", which is OO programming from the MSDN
> website,
> it will demonstrates that this programming paradigm is inefficient with
> a high overhead.
> Why?, this little program is Only doing three simple things, that you
> can do with cobol
> and some win32 API's functions, with much less programming code.
> Regards.
>
>
*>-------------------------------------------------------------------------*
>
> Platform SDK: Windows Management Instrumentation
> *> Example: Creating a WMI Application
> *> The following code example describes a complete WMI client
> *> application that performs COM initialization, connects to WMI
> *> on the local computer, reads some data, and cleans up.
>
> #define _WIN32_DCOM
> #include <iostream>
> using namespace std;
> #include <comdef.h>
> #include <Wbemidl.h>
> # pragma comment(lib, "wbemuuid.lib")
>
> int main(int argc, char **argv)
> {
> HRESULT hres;
>
> // Initialize COM.
> hres = CoInitializeEx(0, COINIT_MULTITHREADED);
> if (FAILED(hres))
> {
> cout << "Failed to initialize COM library. "
> << "Error code = 0x"
> << hex << hres << endl;
> return 1; // Program has failed.
> }
>
> // Initialize
> hres = CoInitializeSecurity(
> NULL,
> -1, // COM negotiates service
> NULL, // Authentication services
> NULL, // Reserved
> RPC_C_AUTHN_LEVEL_DEFAULT, // authentication
> RPC_C_IMP_LEVEL_IMPERSONATE, // Impersonation
> NULL, // Authentication info
> EOAC_NONE, // Additional capabilities
> NULL // Reserved
> );
>
> if (FAILED(hres))
> {
> cout << "Failed to initialize security. "
> << "Error code = 0x"
> << hex << hres << endl;
> CoUninitialize();
> return 1; // Program has failed.
> }
>
> // Obtain the initial locator to Windows Management
> // on a particular host computer.
> IWbemLocator *pLoc = 0;
>
> hres = CoCreateInstance(
> CLSID_WbemLocator,
> 0,
> CLSCTX_INPROC_SERVER,
> IID_IWbemLocator, (LPVOID *) &pLoc);
>
> if (FAILED(hres))
> {
> cout << "Failed to create IWbemLocator object. "
> << "Error code = 0x"
> << hex << hres << endl;
> CoUninitialize();
> return 1; // Program has failed.
> }
>
> IWbemServices *pSvc = 0;
>
> // Connect to the root\cimv2 namespace with the
> // current user and obtain pointer pSvc
> // to make IWbemServices calls.
>
> hres = pLoc->ConnectServer(
>
> _bstr_t(L"ROOT\\CIMV2"), // WMI namespace
> NULL, // User name
> NULL, // User password
> 0, // Locale
> NULL, // Security flags
> 0, // Authority
> 0, // Context object
> &pSvc // IWbemServices proxy
> );
>
> if (FAILED(hres))
> {
> cout << "Could not connect. Error code = 0x"
> << hex << hres << endl;
> pLoc->Release();
> CoUninitialize();
> return 1; // Program has failed.
> }
>
> cout << "Connected to ROOT\\CIMV2 WMI namespace" << endl;
>
> // Set the IWbemServices proxy so that impersonation
> // of the user (client) occurs.
> hres = CoSetProxyBlanket(
>
> pSvc, // the proxy to set
> RPC_C_AUTHN_WINNT, // authentication service
> RPC_C_AUTHZ_NONE, // authorization service
> NULL, // Server principal name
> RPC_C_AUTHN_LEVEL_CALL, // authentication level
> RPC_C_IMP_LEVEL_IMPERSONATE, // impersonation level
> NULL, // client identity
> EOAC_NONE // proxy capabilities
> );
>
> if (FAILED(hres))
> {
> cout << "Could not set proxy blanket. Error code = 0x"
> << hex << hres << endl;
> pSvc->Release();
> pLoc->Release();
> CoUninitialize();
> return 1; // Program has failed.
> }
>
> // Use the IWbemServices pointer to make requests of WMI.
> // Make requests here:
> // For example, query for print queues that
> // have more than 10 jobs
> IEnumWbemClassObject* pEnumerator = NULL;
> hres = pSvc->ExecQuery(
> bstr_t("WQL"),
> bstr_t("SELECT * Win32_PerfFormattedData_Spooler_PrintQue
ue "
> "Where Name <> '_Total'"),
> WBEM_FLAG_FORWARD_ONLY | WBEM_FLAG_RETURN_IMMEDIATELY,
> NULL,
> &pEnumerator);
>
> if (FAILED(hres))
> {
> cout << "Query for print queues failed. "
> << "Error code = 0x"
> << hex << hres << endl;
> pSvc->Release();
> pLoc->Release();
> CoUninitialize();
> return 1; // Program has failed.
> }
> else
> {
> do
> {
> IWbemClassObject* pInstance = NULL;
> ULONG dwCount = NULL;
>
> hres = pEnumerator->Next(
> WBEM_INFINITE,
> 1,
> &pInstance,
> &dwCount);
>
> } while (hres == WBEM_S_NO_ERROR);
>
> }
>
> // Cleanup
> // ========
> pSvc->Release();
> pLoc->Release();
> CoUninitialize();
>
> return 0; // Program successfully completed.
> }
>
>
*>--------------------------------------------------------------------------
-----------*>
>
>

James J. Gavan

2005-02-24, 3:55 am

James J. Gavan wrote:
> Kellie Fitton wrote:
>
> As yet I'm not into Webbing. Are you up to a small challenge, at your
> leisure. The Treeview Demo I've written has five dialogs. Just keep it
> simple to one. We want to edit a cheese so it contains :-
>
> 1) Top right the 'x' for close dialog
> 2) An entry field for the File or DB ID - I'm using pic 9(06)
> 3) Entry field - 20 characters for a cheese name
> 4) A combo dropdown list for countries, Australia, New Zealand, England,
> France etc. I identify them as pic 9(03) in file/DB
> 5) Two pushbuttons - OK and Cancel
>
Kellie,

Oops. A follow-up, to make it complete. I don't have a pushbutton in the
Dialog for 'DELETE'. When the user selects a Cheese with a double-click
from the Treeview, there's a pop-up menu "Add, Change or Delete".
Warning messagebox about deleting - if they respond "Yes" then it gets
deleted from the DB and the Treeview.

Jimmy

Kellie Fitton

2005-02-24, 3:55 pm

James J. Gavan wrote:
> James J. Gavan wrote:
your[color=darkred]
it[color=darkred]
England,[color=darkred]
> Kellie,
>
> Oops. A follow-up, to make it complete. I don't have a pushbutton in
the
> Dialog for 'DELETE'. When the user selects a Cheese with a
double-click
> from the Treeview, there's a pop-up menu "Add, Change or Delete".
> Warning messagebox about deleting - if they respond "Yes" then it
gets
> deleted from the DB and the Treeview.
>
> Jimmy

Kellie Wrote:

I think we should add a "Browse" button to the dialogue as well. If the
user
clicks the browse button, a ListView popup window should provide a
complete
listing of all the entries from the dataBase's masterFile. I don't like
to
use resource files when it comes to including a menu or a dialogue box
in the
graphical window, I prefer to hardCode my resources so I don't have the
needs
to include a .DLL file in my projects. Regards.

Kellie.

Richard

2005-02-24, 3:55 pm

James J. Gavan

2005-02-24, 3:55 pm

> Kellie Wrote:
>
> I think we should add a "Browse" button to the dialogue as well. If the
> user
> clicks the browse button, a ListView popup window should provide a
> complete
> listing of all the entries from the dataBase's masterFile. I don't like
> to
> use resource files when it comes to including a menu or a dialogue box
> in the
> graphical window, I prefer to hardCode my resources so I don't have the
> needs
> to include a .DLL file in my projects. Regards.
>
> Kellie.
>

You might add a Listview - but I'm not - read on !

DESIGN v PROGRAMMING

Your comment, (re Listview) is in the realm where you have put your
'systems analyst' hat on to design so that you are communicating to the
end user. Couldn't agree more.

In ye olden dayse using DOS, display a screen and prompt the user to
enter a Chart of Accounts or Customer Number etc. They were supposed to
remember them. Actually bean counters got very good at memorizing coding
systems. It worked but wasn't terribly helpful.

So with VISOC (predecessor to Net Express), yours truly jumps into OO
and Windowing. (Background - although Dialog System had a history in DOS
days, starting with Panels, it wasn't included in VISOC - just Dialog
Editor and GUI classes. I *think* Dialog System was re-introduced with
one of the versions of N/E V 3.0. As I've indicated, world wide, lots of
folks now using Dialog System as opposed to the Dialog Editor and GUI
class approach).

So now I'm rummaging through books looking for tips and eventually hit
on a paperback, 'Tips on APIs" or something. The author has a screenshot
- simple record input on the left accompanied by a Listbox (not
Listview) on the right. "That's it !", I sez to myself. "That's the
approach I'll take". So using the templates I've dreamed up that's the
route I went - record editing on the left and a Listbox on the right.

Now N/E OO-wise didn't initially mention Listviews but there are Dialog
System demos. I haven't used them but I have a bit of an aversion to
them - they seem to me, at least, to gobble up too much memory
displaying quite a chunk, or even the whole record. (From comments in
Answer Exchange, can be done but a little messy 'editing' individual
columns. Not having gone that route, I can only observe).

Following on the theme 'don't gobble up memory' I keep my elements in a
Listbox to a minimum - Name/Description Key and Other ("Other" depending
upon the file/DB table might be something they want to sort on). Initial
display of the Listbox sorted by default to show names alphabetically.
Just in case - three pushbuttons above Listbox to allow user to see
records sorted by one of the three I've mentioned above.

The logic to keeping Listbox entries to a minimum - why for each element
display 100, 200, or 500 characters for each when the user might only
access three of the records to edit. Click on the Listbox and I
immediately retrieve the specific record from File/DB - the click gives
me the index in the Listbox which is the identical index for the Sorted
Collection where I retrieve the File/DB Key. (Could do the retrieving
via the Listbox - but using Three Tier System approach - I retrieve from
the Sorted Collection outside of the dialog display class).

Then I see one of my smart buddies in Answer Exchange using a Treeview
as the Master Menu to his application. He still allows for traditional
pop-ups and dropdown menus, but the emphasis is on the flexibility of
viewing via the Treeview. Real neat.

Now what I have produced to test the Treeview is :-

Root "Cheese"
Level 1 - Continent
Level 2 - Country
Level 3 - Cheese name

Just to keep it simple. But what I'm really after is the above structure
applied against an oil/gas plant. Expanding the Treeview I have the
equivalent contents of a Listbox (not a Listview, as you suggested).
Think on Listboxes/Listview - I don't think they can easily be an
amalgam of different records (???). But my Treeview approach is - and
from user selection I can edit one of three files/DB depending upon the
Level selected.

Note I still use the Listbox approach for individual files - e.g.
editing Oil Company/Gas Plant names.

DIALOG and RESOURCE

Something else you don't like :-). Come on, you surely must be using
some designing tool to view what you want. If not and you are truly
creating dynamically, then you really are using a pick and shovel
approach - no your aren't - yours is a wheel with four straight sides.

Using the Dialog Editor to create/view my end result, I do have some
dialogs with a lot of entry-fields all of the same nomenclature - so be
damned if I'm gong to identify them as Value1, Value2, Value3 in the
Dialog Editor. My approach - dynamically create them passing x,y, w and
h - but it's a bit of suck-it-and-see initially to get their correct
placement. The x, y, cx, cy in the Dialog Editor can roughly be
translated multiplying by 1.4 or 1.5. (Again one of those MS things -
Horizontal Dialog Units).

Out of curiosity - confirm what you are actually doing to get your
screen image.

DIALOG or DIALOGUE

Which is it. I see you using 'dialogue' which is what I instinctively
use as an ex-Brit. Without thinking to put the spellchecker on
'English-English' as opposed to "Colonial-English" :-) it always picks
me up on my English spelling. Similarly as M/F markets in the former
colonies I assiduously spell it DIALOG EDITOR, just as M/F do.

Jimmy

Kellie Fitton

2005-02-25, 3:55 pm

Hello,

Jimmy, my cobol teacher said:
"if you can't swim with sharks, stay in shallow
waters". ;--))

CHIC vs HAPHAZARD

adding a ListView to your application would
provide flexibility and lucidity --- the end-user
would be able to sort columns based on his or her
desired preference, unlike the listbox, ListView
comes with a neat header control that explains
each column with text labels.

I use the Dialogue Editor to mapOut the x, y, w, h
parameters for any dialogue created dynamically,
then when processing the WM-INITDIALOG
message, you can translate these parameters into
dialogue units, and repaint all controls into a new
position by using the win32 API's
"MapDialogRect", "AdjustWindowRect"
and "SetWindowPos".

DIALOGUE vs DIALOG

my teacher said dialogue is the correct verb since
the purpose of the "dialog" box is to converse with
the end-user. Also, dialogue came originally from
the old french dialogue and the gr

dialogos.

Regards, Kellie.

docdwarf@panix.com

2005-02-25, 3:55 pm

In article <1109349641.720458.133910@z14g2000cwz.googlegroups.com>,
Kellie Fitton <KELLIEFITTON@YAHOO.COM> wrote:

[snip]

>DIALOGUE vs DIALOG
>
>my teacher said dialogue is the correct verb since
>the purpose of the "dialog" box is to converse with
>the end-user. Also, dialogue came originally from
>the old french dialogue and the gr

dialogos.

And whence originally came 'dialog'... from the Portugese for 'day' and
the English 'chunk of a tree'?

According to http://m-w.com/cgi-bin/dictionary?b...onary&va=dialog :

--begin quoted text:

Main Entry: di·a·logue
Variant(s): also di·a·log

--end quoted text

.... and likewise with monologue/monolog, homologue/homolog,
catalogue/catalog, analogue/analog, etc.

DD

Donald Tees

2005-02-25, 3:55 pm

Kellie Fitton wrote:
> Hello,
>
> Jimmy, my cobol teacher said:
> "if you can't swim with sharks, stay in shallow
> waters". ;--))

LOL. Sounds to me like you have a good teacher ... maybe a couple of them.

Donald

Howard Brazee

2005-02-25, 3:55 pm

On 25-Feb-2005, "Kellie Fitton" <KELLIEFITTON@YAHOO.COM> wrote:

> my teacher said dialogue is the correct verb since
> the purpose of the "dialog" box is to converse with
> the end-user.

That reason sort of begs the question. You spell it dialogue because you spell
it dialogue.

The reason software spells it dialog is because it is written in American.

Richard

2005-02-25, 3:55 pm

> my teacher said dialogue is the correct verb

It isn't a verb, or at least shouldn't be.

> Also, dialogue came originally from
> the old french dialogue and the gr

dialogos.

di = two
logos = words or speech

It is irrelevant how the french spell, a computer interaction 'dialog'
is a technical term and may be spelt the way that the originator
decided.

Kellie Fitton

2005-02-25, 3:55 pm

Hi Howard,

"american" is not a language --- in america we
speak english, which came from the old latin,
french and the gr

s. The purpose of a dialogue
box is to have a "Visual Conversation" with the
end-user. Thus, it should be spelled correctly.

Regards, Kellie.

docdwarf@panix.com

2005-02-25, 3:55 pm

In article <1109354625.353288.324170@g14g2000cwa.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
>
>It isn't a verb, or at least shouldn't be.

I don't have my OED with me at the moment... but perhaps someone should
notify the folks at Merriam-Webster and the American Heritage Dictionary
about this... oh, and Shakespeare, Coleridge and Carlyle, as well.

>
>
>di = two
>logos = words or speech

Source, please?

(It has been a few years since I studied it but I recall the 'dia-' prefix
to indicate 'through' (as in 'diameter'); the abovementioned MW and AHD
show the derivation to have come from 'dialegesthai' ('dia-' = through,
'legesthai' = form of legein, an infinitive for 'to speak'... granted that
'logos', a word with many different uses - word, account and ratio are
some - is the noun-form for 'that which is produced when 'legein''... I
think I'd better stop now).)

DD

docdwarf@panix.com

2005-02-25, 3:55 pm

In article <1109354762.140037.255760@f14g2000cwb.googlegroups.com>,
Kellie Fitton <KELLIEFITTON@YAHOO.COM> wrote:
>Hi Howard,
>
>"american" is not a language --- in america we
>speak english, which came from the old latin,
>french and the gr

s.

Well, I guess it is time to drop the 40% or so of the language that is
derived from German/Scadanavian/Norse roots.

>The purpose of a dialogue
>box is to have a "Visual Conversation" with the
>end-user. Thus, it should be spelled correctly.

According to commonly-accepted sources cited previously 'dialog' is a
listed variant of 'dialogue'... some might say this removes it from the
realm of 'incorect'.

DD

James J. Gavan

2005-02-25, 3:55 pm

Kellie Fitton wrote:
> Hello,
>
> Jimmy, my cobol teacher said:
> "if you can't swim with sharks, stay in shallow
> waters". ;--))
>
> CHIC vs HAPHAZARD
>
> adding a ListView to your application would
> provide flexibility and lucidity --- the end-user
> would be able to sort columns based on his or her
> desired preference, unlike the listbox, ListView
> comes with a neat header control that explains
> each column with text labels.
>
No it wouldn't ! Let's go through this one again. I am using a Treeview
to give a user an hierarchial llibrary/catalogue view of getting at
three different files or three different tables in a DB. Think of a true
LIBRARY application based on the Dewey numbering system. That would have
a treeview by topic :-

Art
History
Philosophy etc.

Art takes you to the next Level :-

Painting
Music
Modern Entertainment etc.

Next Level for Modern Entertainment

Movies
Musicals
Plays etc...

Under Movies you are going to get :-

Spartacus
Gone with the Wind
Streetcar Named Desire etc...

Logically, there would be another Level splitting those into Drama,
Musicals, Historical or whatever

So all you need in the Labels is a meaningful description of the
book/video/CD or whatever - then the user clicks on the one they want.

One demo I've seen that comes to mind - click on 'Continent' or 'Area',
gives you say Western Europe. Select next on Germany, which brings up a
map of Germany, with towns/locations highlighted - click on those in the
map and you bring up a photograph of the town/location.

Now back to my Cheese - select the Level for Holland (Country) and it
lists :-

Gouda
Edam etc...

Click on one of those - the Popup Menu has "Add, Change, Delete" - Add
doesn't apply, because you can't add below the Cheese name. To actually
"Add" Gouda Caraway, (that's a 'traditional' they have around Christmas
time), you click on Holland. Delete prompts "Do you want to delete'. If
you want to "Add" a new cheese or "Change" an existing cheese then
that's when the Cheese Dialog comes into play. You already *know* the
contents of your DB from the Treeview display, so a Listbox/Listview is
irrelevant associated with the Cheese Dialog. I'm not disputing use of
either Listbox or Listview - but with a Treeview it's not doing anything
extra for you.

Now in the case of a Cheese Dialog - It's Mickey Mouse, (Code,
Description and a Dropdown to select Country), just to get all the logic
together. But the end application - editing a Vessel (tank) in an
oil/gas plant. Old COBOL file style the record was very small. It has
now changed considerably and using SQL/DB the info is being held in
several different tables relating to Vessels. If I attempted to put all
that in one line of a Listview I can assure you the line entry would
occupy at least four screens. You would drive the user nuts having to
continuously scroll horizontally backwards/forwards to view columns in
the Listview for the particular record.

So thinking back to the simple Cheese Dialog I have a parent Dialog for
Vessel which also brings up some 'child' dialogs, plus - YES - I include
in that Listboxes, (created from other DB tables) to select other
features which have to be added into the total Vessel record being edited.

Get it ? Still not disputing Listboxes/Listviews used in the appropriate
circumstances, but at the first crack, showing the Treeview - for this
particular problem Listbox/Listview are not appropriate - but as I've
shown they can come into play once we get into the nitty-gritty for a
specific Vessel.

> I use the Dialogue Editor to mapOut the x, y, w, h
> parameters for any dialogue created dynamically,
> then when processing the WM-INITDIALOG
> message, you can translate these parameters into
> dialogue units, and repaint all controls into a new
> position by using the win32 API's
> "MapDialogRect", "AdjustWindowRect"
> and "SetWindowPos".
>

I kinda guessed that was what you were doing. Do you ever browse the
on-line help ? Try the following :-

GUI --->
gui-building--->
comparisons--->

There are pluses to using APIs, referred to as coding at the lowest
level. But as well as Advantages there are Di

vantages listed as well.
One Advantage is 'runs faster than others' - you'd never know it - the
OO/GUI approach zips through the stuff as well !

BTW seeing as you made a reference to 'teacher'. Is it Miss Smarty Pants
who decided on going the API route, or is this from your teacher 'cos he
just LUVS APIs ? :-)

Don't expend effort on coding the Cheese Dialog - next one I'll send -
just two programs that create/use the Cheese Dialog.

Jimmy

Howard Brazee

2005-02-25, 3:55 pm

On 25-Feb-2005, "Kellie Fitton" <KELLIEFITTON@YAHOO.COM> wrote:

> "american" is not a language --- in america we
> speak english, which came from the old latin,
> french and the gr

s. The purpose of a dialogue
> box is to have a "Visual Conversation" with the
> end-user. Thus, it should be spelled correctly.

American English spelling is exactly as valid as English English spelling. Or
do you want all English words to return to their non-English sources as well.

"Dialog" is spelled correctly. So is "Dialogue".

Donald Tees

2005-02-25, 3:55 pm

Kellie Fitton wrote:
> Hi Howard,
>
> "american" is not a language --- in america we
> speak english, which came from the old latin,
> french and the gr

s. The purpose of a dialogue
> box is to have a "Visual Conversation" with the
> end-user. Thus, it should be spelled correctly.
>
> Regards, Kellie.
>

Actually, english comes from high german more than the above.

Donald

Kellie Fitton

2005-02-26, 3:55 am

Jimmy,

for my level of experience with cobol language,
which is totally academic and "fun", I don't have
the Leverage that I would like to have without
using or calling the win32 API's system.

standard cobol is perfect for coding the main logic
and the alogrithm to deal with the business rules
and achieve the bottomline. However, nowadays,
this is not enough ---- you need more information
about the target environment that the application
is running on, such as memory size, disk space
available, internet connection, networking access
and business graphics (chart & animations)....etc.

So, I have no choice but to use the win32 API's.
it's fun, it produces the result that I am after, and
I have learned quite a lot from comparing between
C, C++ and cobol the magnificent. Regards.

Kellie.

James J. Gavan

2005-02-26, 3:55 am

Kellie Fitton wrote:
> Hi Howard,
>
> "american" is not a language --- in america we
> speak english, which came from the old latin,
> french and the gr

s. The purpose of a dialogue
> box is to have a "Visual Conversation" with the
> end-user. Thus, it should be spelled correctly.
>
> Regards, Kellie.
>
Just in case you didn't know young lady, Howard is a Yank too :-)

William M. Klein

2005-02-26, 3:55 am

Donald,
I haven't checked this (and Chuck or someone else probably will) but isn't
English derived (or at least in the same branch as) "low German" - not HIGH?

--
Bill Klein
wmklein <at> ix.netcom.com
"Donald Tees" <donald_tees@sympatico.ca> wrote in message
news:viKTd.51695$Am3.1595227@news20.bellglobal.com...
> Kellie Fitton wrote:
>
> Actually, english comes from high german more than the above.
>
> Donald

Richard

2005-02-26, 3:55 am

>> It isn't a verb, or at least shouldn't be.

> I don't have my OED with me at the moment... but perhaps someone
should
> notify the folks at Merriam-Webster and the American Heritage
Dictionary
> about this... oh, and Shakespeare, Coleridge and Carlyle, as well.

I didn't know they programmed for Windows, perhaps PARC had been
working on the Alto for longer than any realised.

As used here 'dialog' is a technical term or jargon. The spelling,
meaning and part is defined by its technical usage, not by an
dictionary of english. For example in 'a dialog box' where it may be
considered to be adjectival.

In other words the word 'dialog' can be spelt, defined and used any way
that the developers of the UI wish.

> 'dia-' prefix to indicate 'through' (as in 'diameter');

You are correct, but di and dia appears to derive from the same root
which variously mean apart (as in two things apart), across, separated,
these all have the connotation of two things. Dialog(ue) is different
from monologue by number.

Richard

2005-02-26, 3:55 am

> However, nowadays, this is not enough ---- you need more
information
> about the target environment that the application is running on,
> such as memory size, disk space available,

Interestingly, I did have code that monitored memory size and disk
space available 20 years ago. This was when running multi-user systems
on 20 and 50 _Mega_byte disk drives. In my view, 'nowadays' (as in the
last dozen years) there is no longer any need to do this.

> internet connection, networking access

I have systems using internet (as both server and client) and
networking on various diverse platforms and my code only trivially
cares about the environment.

> and business graphics (chart & animations)....etc.

While I have hand coded the Windows API in Cobol to draw graphs and
animations*, I doubt that I would bother to do so in future. Just get
a library or component to do it.

* One program drew a perspective 'helm view' of a container ship
showing the containers in their exact place including relative to the
waterline. ie it took into account the displacement, trim and heel (if
any) to show the view over the bow. A modification allowed the
position of the 'helm' to be changed, an undocumented feature was that
a sequence of positions could be specified, eg starting with the
'helm' at -500m and 200m to port, and then it would display a 'fly by'.
On a 486 the frame rate wasn't high.

James J. Gavan

2005-02-26, 3:55 am

Kellie Fitton wrote:
> Jimmy,
>
> for my level of experience with cobol language,
> which is totally academic and "fun", I don't have
> the Leverage that I would like to have without
> using or calling the win32 API's system.
>
> standard cobol is perfect for coding the main logic
> and the alogrithm to deal with the business rules
> and achieve the bottomline. However, nowadays,
> this is not enough ---- you need more information
> about the target environment that the application
> is running on, such as memory size, disk space
> available, internet connection, networking access
> and business graphics (chart & animations)....etc.
>
> So, I have no choice but to use the win32 API's.
> it's fun, it produces the result that I am after, and
> I have learned quite a lot from comparing between
> C, C++ and cobol the magnificent. Regards.
>
> Kellie.
>
Don't' disagree with that Kellie, but here's the rub - APIs are MS
Windows-centric. From info I received useless with Unix. Linux,
something else again.

Where are you going career wise.

Mainframe - Uggh. Not a criticism of mainframe, for which there is still
a market, but to my mind, I would hate being just another numbered
employee in a big set up. Worked as an analyst with mainframes, small
teams at first, we grew and I was one of the bosses - but oh my gawd the
internal company politics to get things approved and then done. Note
there's an awful lot of outsourcing being applied to mainframes. IBM
(their own software teams) have just grabbed a juicy contract up here to
run the federal Wheat Board applications. And that's not the first one
that IBM have grabbed up here.

PCs - Windows/Unix/Linux whatever - seems to me that's more likely where
your career will take you - something like a 6-10 person software house
where you could have real fun. Your API knowledge may be beneficial to
some employers but others are going to quiz, "Do you know C++, Java,
scripting, dotNet, ASP or whatever....?". In one way or another these
all point at OO.

I'm talking basic OO - then you get into the nuances of how the
different tools/languages are applied - when you have that understanding
of general OO principles. N/E is a a good comprehensive tool - totally
ignoring GUI-ing, given time, try things in OO and think how you can
apply, to me at least, the most important word in OO - REUSE.

I know absolutely NOTHING about webbing, but N/E has a module called
FORMS - from looking at Answer Exchange, could be wrong, but get the
impression there aren't too many using it. It does produce Web pages -
but of course there are alternatives. I wouldn't kind betting that if I
plugged away with REUSE - I could add flexibility and probably get the
Forms module to do what I want. Haven't tried it - but that Forms module
lets you play just on your own machine using a feature called SOLO.

Note also I said, I think the majority of M/F developers are using
Dialog System. Why ? My best guess, and not unnaturally, a reticence to
get into OO - although to fine tune Dialog System they can use OO and
invoke existing classes or write their own.

Hopefully the source I've just posted, not the nitty-gritty, but the
concept of REUSE comes across.

Jimmy

Howard Brazee

2005-02-26, 3:55 am

On 25-Feb-2005, "Richard" <riplin@Azonic.co.nz> wrote:

> As used here 'dialog' is a technical term or jargon. The spelling,
> meaning and part is defined by its technical usage, not by an
> dictionary of english. For example in 'a dialog box' where it may be
> considered to be adjectival.

The word used here is the same as the word "dialog" is in that subset of English
used by the people who used it to describe a computer dialog. The word isn't
an accident. It wasn't an intentional misspelling.

> In other words the word 'dialog' can be spelt, defined and used any way
> that the developers of the UI wish.

And they used it, spelled it, and defined it to match the word "dialog".

Englishmen would have been perfectly consistent to translate this technical term
when it crossed the Atlantic.

Howard Brazee

2005-02-26, 3:55 am

On 25-Feb-2005, "James J. Gavan" <jgavandeletethis@shaw.ca> wrote:

> Mainframe - Uggh. Not a criticism of mainframe, for which there is still
> a market, but to my mind, I would hate being just another numbered
> employee in a big set up. Worked as an analyst with mainframes, small
> teams at first, we grew and I was one of the bosses - but oh my gawd the
> internal company politics to get things approved and then done. Note
> there's an awful lot of outsourcing being applied to mainframes. IBM
> (their own software teams) have just grabbed a juicy contract up here to
> run the federal Wheat Board applications. And that's not the first one
> that IBM have grabbed up here.
>
> PCs - Windows/Unix/Linux whatever - seems to me that's more likely where
> your career will take you - something like a 6-10 person software house
> where you could have real fun.

There still are significant numbers of 6-10 programmer mainframe shops.

Chuck Stevens

2005-02-26, 3:55 am

Yes. The closest structural relatives to English are Frisian and Dutch, I'd
say. Relationship to Plattdeutsch depends on how you define the latter
term. Basic consonant patterns are the most obvious characteristic of "High
German", reflecting an eighth-century shift in that particular language.
From Wikipedia:

Low German (North Saxon): Ik segg et/dat up
Nedderdüütsch/Platt(düütsch).
Low German (Mennonite Plautdietsch): Ekj/Etj saje et op
Nadadietsch/Plautdietsch.
Standard Dutch: Ik zeg het in het Nederduits/Platduits.
High (Standard) German: Ich sage es auf Niederdeutsch/Platt(deutsch).
English: I say it in Low German.

Pity no example from Frisian. At home I've got a citation that reads the
same in both English and Frisian; don't have it handy here, though. They're
amazingly close.

-Chuck Stevens

"William M. Klein" <wmklein@nospam.netcom.com> wrote in message
news:krLTd.3384565$f47.608498@news.easynews.com...
> Donald,
> I haven't checked this (and Chuck or someone else probably will) but
isn't
> English derived (or at least in the same branch as) "low German" - not
HIGH?
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com
> "Donald Tees" <donald_tees@sympatico.ca> wrote in message
> news:viKTd.51695$Am3.1595227@news20.bellglobal.com...
>
>

Donald Tees

2005-02-26, 3:55 am

William M. Klein wrote:
> Donald,
> I haven't checked this (and Chuck or someone else probably will) but isn't
> English derived (or at least in the same branch as) "low German" - not HIGH?
>

I just checked my source, Bill, and it says:
"germanic-->west germanic
"west germanic-->old english-->middle english-->english", then in
another column
"west germanic-->old low german-->middle low german-->low german" and in
a third
"west germanic-->old high german-->middle high german-->high german and
yiddish"

So it looks like we are both wrong ... west germanic was the root of
both high and low german, and english.

There are also, according to this reference, a north germanic and an
east germanic. The north germanic evolved into icelandic, norwegian,
swedish and danish, while the east germanic evolved into gothic.

Donald

James J. Gavan

2005-02-26, 3:55 am

Chuck Stevens wrote:
> Yes. The closest structural relatives to English are Frisian and Dutch, I'd
> say. Relationship to Plattdeutsch depends on how you define the latter
> term. Basic consonant patterns are the most obvious characteristic of "High
> German", reflecting an eighth-century shift in that particular language.
> From Wikipedia:
>
> Low German (North Saxon): Ik segg et/dat up
> Nedderdüütsch/Platt(düütsch).
> Low German (Mennonite Plautdietsch): Ekj/Etj saje et op
> Nadadietsch/Plautdietsch.
> Standard Dutch: Ik zeg het in het Nederduits/Platduits.
> High (Standard) German: Ich sage es auf Niederdeutsch/Platt(deutsch).
> English: I say it in Low German.
>
>
> Pity no example from Frisian. At home I've got a citation that reads the
> same in both English and Frisian; don't have it handy here, though. They're
> amazingly close.
>

I knew, I knew I shouldn't have mentioned dialog/dialogue to Kellie -
yet another thread takes off on its own tangent :-). I knew the
'Language Man' would jump in :-)

Now regarding the Frisian - do you recall either the TV show (PBS) or
follow-up book, 'The Story of English', by Robert McNeil from the
McNeil-Lehrer Report days ? (An ex-Canuck who took US citizenship about
a year ago).

There's a scene where they go up to Friesland (if that's the correct
name) and get a local farmer to speak. Two I recall distinctly 'cow' and
'butter' - first came out "kowooo" and second 'buddr' - really
fascinating. Then of course there's 'kerk' and the Scottish 'kirk'.

Back to Dialog - can't remember who pointed it out; Richard or Howard I
think. Their/His observation makes sense. It's a technical term so a
computer DIALOG is perfectly kosher.

Jimmy

docdwarf@panix.com

2005-02-26, 3:55 am

In article <1109361297.008867.304890@g14g2000cwa.googlegroups.com>,
Richard <riplin@Azonic.co.nz> wrote:
>
>
>I didn't know they programmed for Windows, perhaps PARC had been
>working on the Alto for longer than any realised.

Learn something new every day, aye.

>
>As used here 'dialog' is a technical term or jargon. The spelling,
>meaning and part is defined by its technical usage, not by an
>dictionary of english. For example in 'a dialog box' where it may be
>considered to be adjectival.

The original post states 'my teacher said dialogue is the correct verb
since the purpose of the "dialog" box is to converse with the end-user.';
the noun and the verb appear to be clearly differentiated. The box may be
a 'dialog box' but it is used to dialogue (or dialog) with the user.

>
>In other words the word 'dialog' can be spelt, defined and used any way
>that the developers of the UI wish.
>
>
>You are correct, but di and dia appears to derive from the same root
>which variously mean apart (as in two things apart), across, separated,
>these all have the connotation of two things. Dialog(ue) is different
>from monologue by number.

Whence it came, Mr Plinston, and whence it wound up might just possibly
not be the same; diaphanous and diabolical seem to have little sense of
'two-ness'. The difference between dialogue and monologue seems that one
is a speaking-through and the other is a talking-alone... or are you
saying that dialogue should really be dilogue and the 'a' was just kept
for... some reason or another?

DD

Chuck Stevens

2005-02-26, 3:55 am

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:_HMTd.505784$Xk.226092@pd7tw3no...

> Now regarding the Frisian - do you recall either the TV show (PBS) or
> follow-up book, 'The Story of English', by Robert McNeil from the
> McNeil-Lehrer Report days ? (An ex-Canuck who took US citizenship about
> a year ago).
>
> There's a scene where they go up to Friesland (if that's the correct
> name) and get a local farmer to speak. Two I recall distinctly 'cow' and
> 'butter' - first came out "kowooo" and second 'buddr' - really
> fascinating. Then of course there's 'kerk' and the Scottish 'kirk'.

Missed it.

There's a fascinating (to me, anyway) Old Norse influence through the
Vikings, where we end up with two variants of the same Germanic root:
shirt/skirt and ship/skiff being two such pairs that come to mind offhand.

One time I heard a group of people on the plane speaking what sounded a
whole lot like somewhat-accented English, except that I couldn't make out a
single word. When I got to the airport, I asked one of them what it was;
turned out to be Icelandic, which is from what I've heard pretty much Old
Norse preserved largely intact. While Frisian and Dutch are like siblings
of English, I'd say Icelandic is like an uncle. The other modern
Scandinavian languages, along with High German, are cousins.

The distinction between two dialects of the same language and two languages
in the same family is often a fine, and arbitrary, one, and I don't think
the distinction between, say, the West Germanic language of the Angles,
Jutes, Saxons and Frisians at the time they invaded the British Isles and
the North Germanic language of southern Scandinavia at the same time was all
that great (Iceland was settled a couple of centuries later).

-Chuck Stevens.

Kellie Fitton

2005-02-26, 3:55 am

Jimmy,

the so-called "ObjectOriented" methodologies are over 25
years old. However, object-oriented Technology has not been
the "Magic Bullet". You are referring to the term "Reuse" more
loosely, as though it is the Net-Result of using OO
programming --- this is NOT TRUE. This is the fallacy in their
salesmanship approach, when they are pitching their OO
ideas. In the real IS world with real-world business
applications, Reuse doesn't work. it's just a fancy term used
by the OO proponents to justify their inEfficient and
unPractical programming paradigm. Their is a major difference
between claiming you have achieved "Reusability" and proving
it.

Standard cobol have been "Reusable" for more than 25
years, How? simply by programming the cobol code as a
standalone functions and callable sub-routines, that can be
shared among applications, as a copybook or a library file.
So, the term "Reuse" is NOT new to cobol the magnificent.

don't be fooled by the fancy terminology the OO pushers
uses, these are just some marketing devices to lure the
innocent into their traps. Why, its called money or making a
living. Just remember, OO paradigm is just an idea, NOT a
solution to save the ozone layer from the CFC gases.

Regards, Kellie.

Richard

2005-02-26, 3:55 am

> The original post states 'my teacher said dialogue is the correct
verb
> since the purpose of the "dialog" box is to converse with the
end-user.';

It also had:

Which I would say is a) incorrect because it is a product name, b) if
it wasn't a trade name, is using 'dialogue' as a noun, possibly
adjectivally.
[color=darkred]
> it is used to dialogue (or dialog) with the user.

While you may be contriving to use the word as a verb I would suggest
that is unusal usage, especially in recent times. It would be more
common to say that it interacts.

Of course americans seem to be able to abuse the language in more ways
than I can imagine.

James J. Gavan

2005-02-26, 3:55 am

Kellie Fitton wrote:
> Jimmy,
>
> the so-called "ObjectOriented" methodologies are over 25
> years old. However, object-oriented Technology has not been
> the "Magic Bullet". You are referring to the term "Reuse" more
> loosely, as though it is the Net-Result of using OO
> programming --- this is NOT TRUE. This is the fallacy in their
> salesmanship approach, when they are pitching their OO
> ideas. In the real IS world with real-world business
> applications, Reuse doesn't work. it's just a fancy term used
> by the OO proponents to justify their inEfficient and
> unPractical programming paradigm. Their is a major difference
> between claiming you have achieved "Reusability" and proving
> it.
>
> Standard cobol have been "Reusable" for more than 25
> years, How? simply by programming the cobol code as a
> standalone functions and callable sub-routines, that can be
> shared among applications, as a copybook or a library file.
> So, the term "Reuse" is NOT new to cobol the magnificent.
>
> don't be fooled by the fancy terminology the OO pushers
> uses, these are just some marketing devices to lure the
> innocent into their traps. Why, its called money or making a
> living. Just remember, OO paradigm is just an idea, NOT a
> solution to save the ozone layer from the CFC gases.
>
> Regards, Kellie.
>
I hope to God you wrote this BEFORE looking at my second message showing
code. If you still persist in the above statement HAVING studied what
that code is doing - then you are incorrigible.

Where are you picking this anti-OO crap up from. Is your 'teacher'
anti-COBOL, anti-OO or what. I'll take a guess you are below 25 years of
age - you do appear to have a very closed mind on this topic.

Over and out - no more discussion.

Jimmy

Richard

2005-02-26, 3:55 am

> the so-called "ObjectOriented" methodologies are over 25
> years old.

Developed in Simula the standard for which was 1967, nearly 40 years
ago.

> However, object-oriented Technology has not been the "Magic Bullet".

Actually it does solve problems more easily than other mechanism do.

> Standard cobol have been "Reusable" for more than 25
> years, How? simply by programming the cobol code as a
> standalone functions and callable sub-routines, that can be
> shared among applications, as a copybook or a library file.
> So, the term "Reuse" is NOT new to cobol the magnificent.

That is true. And many languages have had reusability, mainly via
libraries, for as long as Cobol. The advantage that Cobol has had has
been the dynamic loading which could be done in other languages but was
not usual at the time that C++ was developed.

As I have said many times, OO is mainly solutions to problems that
Cobol did not have.

However, OO Cobol does have some advantages, as I pointed out in
another thread. Reusability is more than just from one program to the
next, with OO you can reuse in the _same_ program.

My example was a raw print output. The OO version catered for multiple
simultaneous streams from one program whereas with the subroutine
version this would have had to rely on sequential reuse.

In the case of a GUI application this may be divided into many modules
or subroutines, for example each catering for a different dialog. This
means that each can only be used once at one time in a run-unit. If,
for example, you have a 'message box' subroutine then if it is
activated from two parts of the program (ie it is active and another
routine calls it) then the program may crash. If the code is in a
class then multiple instances can be created without crashing.

You are hand coding each dialog. This has several problems, mainly you
will be rewriting much of the same code over and over again.
Inheretance is another feature of OO. The ability to say: just like
that but with these changes. This reuses code in quite a different
way.

Kellie Fitton

2005-02-26, 3:55 am

Richard,

standard cobol can Reuse code in the same
program as well, its called:
local entry-point function,
global entry-point function and
Recursive functions. Right?

Kellie.

Richard

2005-02-26, 3:55 am

> standard cobol can Reuse code in the same program as well, its
called:
> local entry-point function, global entry-point function and
> Recursive functions. Right?

Yes, you can. The issue is that the program code needs to be aware that
this is occuring and to explicitly cater for it. For example if one
routine was maintaining more than one copy of a dialog it would need to
keep the persistent data (such a sthe handle(s)) in an array or some
other structure to retain this and it would need to manage this
explicitly. Local-storage is created afresh at each activation.

William M. Klein

2005-02-26, 3:55 am

Up until the '02 Standard (and - to the best of my knowledge - there is no
"fully conforming" '02 compiler)

Recursion is not allowed
Local-Storage didn't exist

and ENTRY statements aren't in any current (recent, or foreseeable future)
Standard.

...

so how does this fit with your statement,

"standard cobol can Reuse code in the same ..."

Have you tried compiling any of your programs with "standard flagging" turned on
to see exactly what IS and is NOT "standard" (and, thereby, portable to any
"standard conforming" compiler)?

--
Bill Klein
wmklein <at> ix.netcom.com
"Kellie Fitton" <KELLIEFITTON@YAHOO.COM> wrote in message
news:1109374524.736063.195070@g14g2000cwa.googlegroups.com...
> Richard,
>
> standard cobol can Reuse code in the same
> program as well, its called:
> local entry-point function,
> global entry-point function and
> Recursive functions. Right?
>
> Kellie.
>

Kellie Fitton

2005-02-26, 3:55 am

Bill,

Recursion:
if you have a Micro Focus cobol compiler, Recursion (or recursive
routines) is allowed,
supported and its well documented in their language reference manual.
However, you
must declare a Local-Storage Section in your program to be able to use
a recursive
function. Here is an example from micro focus's help manual:

identification division.

program-id. family.

working-storage section.

01 family-tree.
03 individual occurs 50.
05 ind-name pic x(30).
05 eldest-pointer pic 9(2).
05 sibling-pointer pic 9(2).

local-storage section.
01 tree-pointer pic 9(2).

linkage section.
01 parent-pointer pic 9(2).

procedure division.
0001-main.
move 1 to tree-pointer
call "children" using tree-pointer
stop run.

entry "children" using parent-pointer
move eldest-pointer(parent-pointer) to tree-pointer
if tree-pointer = 99
display ind-name(parent-pointer)
else
perform until tree-pointer = 99
call "children" using tree-pointer
move sibling-pointer(tree-pointer) to tree-pointer
end-perform
end-if.

Entry-Point:
like wise, entry points are allowed, supported and well documented. In
fact, the compiler
has two directives to handle entry points function, they are:
"STICKY-LINKAGE" and
"LITLINK". Here is an entry example from their help manual:

The ENTRY statement establishes an alternate entry-point into a called
COBOL program.

ENTRY literal-1
USING [BY REFERENCE] {data-name-1}
[BY VALUE ] {data-name-2}

Flagging:
I used flagging directives when I compiled my program that have an
entry-points and
recursive functions or routines, no error messages were displayed. Here
is some
directives from their help manual:

FLAGAS, FLAGCD, FLAGSTD, FLAGQ, FLAGSINEDIT

Makes the Compiler produce language-level certification flags when it
finds syntax that is
not part of a specified level of the ANSI'85 Standard.
Copyright (C) 2000 MERANT International Ltd. All rights reserved.

Regards, Kellie.

LX-i

2005-02-26, 3:55 am

Richard wrote:
>
> Of course americans seem to be able to abuse the language in more ways
> than I can imagine.

It's a gift... :)

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~
~ / \ / ~ Live from Montgomery, AL! ~
~ / \/ o ~ ~
~ / /\ - | ~ daniel@thebelowdomain ~
~ _____ / \ | ~ http://www.djs-consulting.com ~
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
~ GEEKCODE 3.12 GCS/IT d s-:+ a C++ L++ E--- W++ N++ o? K- w$ ~
~ !O M-- V PS+ PE++ Y? !PGP t+ 5? X+ R* tv b+ DI++ D+ G- e ~
~ h---- r+++ z++++ ~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~

Richard

2005-02-26, 3:55 am

> if you have a Micro Focus cobol compiler, Recursion (or recursive
routines) is allowed,

Your claim was that "STANDARD Cobol can ..."

Bill pointed out that recusrion and local-storage are extensions in '85
compilers and ENTRY is not standard at all.

If you are using the directives and not getting flagged for these then
you should review how your compiler is running.

Rick Smith

2005-02-26, 3:55 am

"Kellie Fitton" <KELLIEFITTON@YAHOO.COM> wrote in message
news:1109386135.116637.12970@o13g2000cwo.googlegroups.com...
> Bill,
>
> Recursion:
> if you have a Micro Focus cobol compiler, Recursion (or recursive
> routines) is allowed,
> supported and its well documented in their language reference manual.
[snip]
> FLAGAS, FLAGCD, FLAGSTD, FLAGQ, FLAGSINEDIT
>
> Makes the Compiler produce language-level certification flags when it
> finds syntax that is
> not part of a specified level of the ANSI'85 Standard.
> Copyright (C) 2000 MERANT International Ltd. All rights reserved.

Here is the listing for the sample program with checking for
ANSI 85 conformance.

* Micro Focus COBOL Version 3.2.24 L2.5 revision 000 25-Feb-05 22:32 Page
1
* C:\CBL-CHAL\TREE.cbl
* Options: anim ensuite(2) wb errq editor(mf) noosvs nodosvs novsc2
nocobol370 a
1$set nomf ans85 flag"ans85" flagas"S"
2 identification division.
3
4 program-id. family.
5
6 working-storage section.
* 135-S*************** (
0)**
** DATA DIVISION missing
7
8 01 family-tree.
9 03 individual occurs 50.
10 05 ind-name pic x(30).
11 05 eldest-pointer pic 9(2).
12 05 sibling-pointer pic 9(2).
13
14 local-storage section.
* 71-S************* (
1)**
** PROCEDURE DIVISION missing or unknown statement
* 10-S************* (
1)**
** Word starts or is continued in wrong area of source line
15 01 tree-pointer pic 9(2).
16
17 linkage section.
18 01 parent-pointer pic 9(2).
19
20 procedure division.
21 0001-main.
22 move 1 to tree-pointer
23 call "children" using tree-pointer
24 stop run.
25
26 entry "children" using parent-pointer
* 10-S********* (
1)**
** Word starts or is continued in wrong area of source line
* 9-S********* (
1)**
** '.' missing
* 10-S******************** (
1)**
** Word starts or is continued in wrong area of source line
* 3-S******************** (
1)**
** Illegal format : Literal
27 move eldest-pointer(parent-pointer) to tree-pointer
28 if tree-pointer = 99
29 display ind-name(parent-pointer)
30 else
31 perform until tree-pointer = 99
32 call "children" using tree-pointer
33 move sibling-pointer(tree-pointer) to tree-pointer
34 end-perform
35 end-if.
* Micro Focus COBOL Version 3.2.24 L2.5 revision 000
* Last message on page: 1
*
* Total Messages: 7
* Unrecoverable : 0 Severe : 7
* Errors : 0 Warnings: 0
* Informational : 0 Flags : 0
* Data: 2196 Code: 161