Treeviews

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

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 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

"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

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

"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.
>
>

"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

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.

> 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).

> 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.