Re: Calling All SOM gurus

[Jonathan de Boyne Pollard]

>
>
> Do you know if there is such a thing as a visual SOM class?
>
What do you think one of those actually is? It's not really a
description that makes a lot of sense. One might just as well ask
whether there's such a thing as "visual main() function".

One can create a SOM class library to wrap the PM API, with classes for
wrapping the different types of PM windows. I did that myself, quite a
few years ago, as a matter of fact. I've even published programs that
use it. You'll find a subset of it in my 32-bit Command Interpreter,
for example. It's what the PMCMD front-end uses. WINSIGHT, in my
Command Line Utilities, also uses it.

[Galen Henderson]

Hi Jonathan. Thanks for the response. I was reading in the VAB
documentation which has very little about SOM and it said that if you
are creating a non-visual class then... I took this to mean that there
is a visual SOM class that can be used as a control much like an activex
control is used in the M$ world. It can have an interface or can
include multiple controls that can all be wrapped into a SOM object.

I would love to look at your code as it seems like you have done what I
would like to learn. If you could point me to where I can download some
source code, that would be really helpful.

Thanks Again,

--
Regards,
Galen
-----
There are only 10 kinds of people in the world. Those who understand
binary and those who don't.

[Lars Erdmann]

Hallo Galen,

> Hi Jonathan. Thanks for the response. I was reading in the VAB
> documentation which has very little about SOM and it said that if you are
> creating a non-visual class then... I took this to mean that there is a
> visual SOM class that can be used as a control much like an activex
> control is used in the M$ world. It can have an interface or can include
> multiple controls that can all be wrapped into a SOM object.

You are talking about "Visual Builder" ? Then yes, they have SOM classes
that have a visual representation (something that can be seen on screen) and
classes that do not.
But the visual classes do not change the "basic" look and behaviour of
window classes. What the SOM object really does is wrap the "Win" API
functions (WinCreateWindow, WinShowWindow etc.) to be available as SOM
methods.
If you really want to CHANGE the window class itself, you will have to
sub/superclass the window procedure in your SOM class anyway.

Lars

[Galen Henderson]

Lars, thanks for more great info. I guess I wanted to be able to
somehow encapsulate a Notebook or Container control in such a way that I
can create and use it's properties and methods in a SOM enabled
environment such as VAB. I guess I don't really need to subclass it,
just be able to encapsulate the API functions as you suggest so that I
can manipulate the oblect (add notebook pages, etc) from VAB or other
SOM compliant environments so I could use it to supplement the limited
controls that ship with VAB

[Jonathan de Boyne Pollard]

>
>
> I took this to mean that there is a visual SOM class that can be used
> as a control much like an activex control is used in the M$ world. It
> can have an interface or can include multiple controls that can all be
> wrapped into a SOM object.
>

That's just a class. There's nothing really that makes it specifically
"visual". Classes can encapsulate many things. The PM API is one.
Yes, it's possible to create SOM classes that form the components of a
"visual" programming environment. It's also possible to create
(compiler-specific) ordinary C++ classes to do so. Several people
already have, in several different products, long since.

[Galen Henderson]

Jonathan, thanks for the reply. I'll be researching this as I want to
extend VAB with some more controls.

Thanks Again.

[Lars Erdmann]

Galen Henderson schrieb:

In that case you are on the right track. Yes, encapsulation of the "Win" API can most certainly be done.

Lars