[VOCOM] - any expieriences with creating Automation Server Interfaces?
ilias
looks that i cannot rely on the COMSDK/Authors for creating production
grade software.
-
Prior to use COMSDK, i take a quick look at VOCOM. I understand that
it is designed for handling COM-objects in VO, but not directly for
creating interfaces to Automation Servers in VO.
Did anyone use this library for contacting(!) automation servers with
events?
FDW
Why would you say a thing like that ?
Frans
"ilias" <use...@abeon.com> wrote in message
news:35a10d4c.03060...@posting.google.com...
ilias
> ilias
[ilias has copied this answers manually down into context]
> Frans
>
>
> "ilias" <use...@abeon.com> wrote in message
> news:35a10d4c.03060...@posting.google.com...
> > I use COMSDK for the creation of an Automation-Server-Interface. It
> > looks that i cannot rely on the COMSDK/Authors for creating production
> > grade software.
> Why would you say a thing like that ?
See this topic (if you like to comment, please use this topic):
[COMSDK] - Bug Report/Fix: BSTR* [in,out]
http://groups.google.com/groups?selm=35a10d4c.03060...@posting.google.com
You can read additionally this topics:
[COMSDK] Current Version, download location
http://groups.google.com/groups?selm=3ED67119...@null.com
HowTo return an OLE String in an Automation Server Interface
http://groups.google.com/groups?selm=3ED62964...@null.com
Geoff Schaller
> I use COMSDK for the creation of an Automation-Server-Interface. It
> looks that i cannot rely on the COMSDK/Authors for creating production
> grade software.
You must be the only person on the planet to experience this. Excepting you,
I know of no-one, totally no-one, who hasn't been able to contact either
Frans or Ed to deal with any issue confronting them.
I presume you tried this?
Geoff
Gary Stark
Geoff Schaller wrote:
He's been quite successful in contacting them, but he doesn't seem to appreciate
the fact that what Ed and Frans are doing they're doing in their own free time.
He's failing (or refusing) to accept and appreciate that Frans and Ed might have
other priorities, like earning a living so that they can feed their families.
IMHO Ilias is being rather strenuous with his demands on others, but doesn't (as
yet) appear to contributed anything to this community himself.
He's almost a Steve Rowe in his negativity and demands. I suspect he'll go a
long way and I anticipate that there'll be a queue of willing contributors for
the cost of the one-way ticket. <g>
--
g.
Gary Stark
gst...@RedbacksWeb.com
http://RedbacksWeb.com
Ed Ratcliffe
<VBG>
Rod da Silva
I am the author of VOCOM. VOCOM is a COM library for VO. With it you can
program COM interfaces and COM objects (servers). The library has standard
implementations for only a few core COM interfaces such as IUnknown,
IClassFactory, IDisptach, etc.. The rest are up to you to program in COM.
OLE Events are implemented with IConnectionPoint and
IConnectionPointContainer among others. Implementing events is an exercise
in programming COM. You can use VOCOM to do this if you like, but you have
to be willing to rol up your sleves and do some COM programming.
FWIW, it is my understanding that COMSDK was designed specifically to
address support for events in OLE. To that extent you might think of that
library as being one level up from my low-level library, so I expect it
would be easier (i.e.; less code to write) to use COMSDK then VOCOM to
support OLE events. However, I say this without ever having an occassion to
look at COMSDK so I might be way off track here, in which case Ed or Frans
will correct me.
HTHs,
Rod
FDW
Let me correct you ;-)
The COMSDK was ( and is ) being developed as an tool to implement clients
for COM servers. There is at this time no 'Toy' to automate the creation of
the classes. The tool comes with a help file that describes the classes and
functions of the library. Also there is an extensive example for using the
'Outlook' server, that includes demo's of using/implementing events. Besides
this there is a tutor include that describes how to design your own COM
clients ( including event handlers ).
All this is ( and will be ) supported by Ed and me, all issues that need
immediate attention of us will be dealt with in the shortest possible time.
Matters that are less time pressed may be delayed somewhat ( we have to earn
our money also ).
Best Regards
Frans
"Rod da Silva" <RodDa...@NOSPAM.com> wrote in message
news:bbqg2a$8b8$1...@ngspool-d02.news.aol.com...
ilias
<ge...@softwareREMobjectives.com.au> wrote:
>Ilias,
>
>> I use COMSDK for the creation of an Automation-Server-Interface. It
>> looks that i cannot rely on the COMSDK/Authors for creating production
>> grade software.
>
>You must be the only person on the planet to experience this. Excepting you,
>I know of no-one,
As you don't know, i must be the only person.
I understand your conclusion.
>totally no-one, who hasn't been able to contact either
>Frans or Ed to deal with any issue confronting them.
"i cannot rely" not "i cannot contact"
>
>I presume you tried this?
of course.
>
>Geoff
>
>
ilias
<RodDa...@NOSPAM.com> wrote:
>Ilias
>
>I am the author of VOCOM. VOCOM is a COM library for VO. With it you can
>program COM interfaces and COM objects (servers). The library has standard
>implementations for only a few core COM interfaces such as IUnknown,
>IClassFactory, IDisptach, etc.. The rest are up to you to program in COM.
>OLE Events are implemented with IConnectionPoint and
>IConnectionPointContainer among others. Implementing events is an exercise
>in programming COM. You can use VOCOM to do this if you like, but you have
>to be willing to rol up your sleves and do some COM programming.
i understand.
>FWIW, it is my understanding that COMSDK was designed specifically to
>address support for events in OLE. To that extent you might think of that
>library as being one level up from my low-level library, so I expect it
>would be easier (i.e.; less code to write) to use COMSDK then VOCOM to
>support OLE events. However, I say this without ever having an occassion to
>look at COMSDK so I might be way off track here, in which case Ed or Frans
>will correct me.
Two 3rd party products for VO which deal with COM (although different
parts of it)
VOCOM.
COMSDK.
additionally, the native VO support for COM
-
This is very much. And it looks, like all this is totally
unsynchronized.
I think, VOCOM was first.
Thus COMSDK should rely on this knowledge/design.
Just thoughts.
-
Anyway, thanks for your answer.
>
>HTHs,
>
>Rod
>
FDW
I will not go into these items and I will not discuss these items. What I
will do is, I will have a look at the function(s) you found that is not
working properly, and ( whether you like it or not ) I will fix the problem.
This may take some time due to the fact that I have to find/create a
situation that creates the problem ( as you did not give to me ) and then I
have to confirm if the solution provided by you ( thanks for that ) works as
intended. When this all is done I will let you know.
ilias
wrote:
>Ilias,
>
>I will not go into these items and I will not discuss these items. What I
[...]
>intended. When this all is done I will let you know.
You have written all this in another thread. My answer is there:
http://groups.google.com/groups?selm=bbvm5j$7la$1...@newsreader.mailgate.org
Malcolm Gray
> Two 3rd party products for VO which deal with COM (although different
> parts of it)
>
> VOCOM.
>
> COMSDK.
>
> additionally, the native VO support for COM
>
> -
>
> This is very much. And it looks, like all this is totally
> unsynchronized.
some of them happened IIRC from previous postings and
articles in SDT.
> I think, VOCOM was first.
I _think_ CAs limited classes were first, but I could be wrong.
> Thus COMSDK should rely on this knowledge/design.
Umm, VOCOM was launched as a commercial product whose source
was not normally available and some restrictions on creating equivalents
products with it (I could not buy VOCOM and then give it all away
for free for example) - until VO2.6 Rod sold individual licenses,
are you saying he should have given that knowledge away for free?
Malcolm
ilias
<malcol...@jobstream.co.uk> wrote:
>
>"ilias" <use...@abeon.com> wrote in message
>news:bbrb4l$2ed$2...@newsreader.mailgate.org...
[...]
>> This is very much. And it looks, like all this is totally
>> unsynchronized.
>Well Rod asked for changes in VO and at least
>some of them happened IIRC from previous postings and
>articles in SDT.
i see.
>> I think, VOCOM was first.
>I _think_ CAs limited classes were first, but I could be wrong.
If so, then VOCOM should rely on the design of those.
Optimum: replaces completely but in compatible way.
>> Thus COMSDK should rely on this knowledge/design.
>
>Umm, VOCOM was launched as a commercial product whose source
>was not normally available and some restrictions on creating equivalents
>products with it (I could not buy VOCOM and then give it all away
>for free for example) - until VO2.6 Rod sold individual licenses,
>are you saying he should have given that knowledge away for free?
not necessarily
COMSDK becomes a 'addon' to VOCOM.
COMSDK users have still to purchase VOCOM to use COMSDK.
>
>Malcolm
>
Malcolm Gray
> >> I think, VOCOM was first.
> >I _think_ CAs limited classes were first, but I could be wrong.
>
> If so, then VOCOM should rely on the design of those.
(as CAs classes and VOCOM have done)
> Optimum: replaces completely but in compatible way.
I think I would agree with that in the cases
where the problems with the thing you are replacing
are not themselves in the design then complete
compatibility is optimum but not always worth
it in a cost benefit case - how much extra would
you pay for this ability from a third party?
What element of VOCOM is giving you a problem as
an incompatibility between the two?
(I have code I can use with either for example)
Equally how much extra would you pay/expect others
to pay for COMSDK (or VO2.6) for it to be based on
VOCOM.
Malcolm Gray
> >> I think, VOCOM was first.
> >I _think_ CAs limited classes were first, but I could be wrong.
>
> If so, then VOCOM should rely on the design of those.
>
> Optimum: replaces completely but in compatible way.
From memory given a CA, VOCOM or Vo2ADO COM object
there is nothing stopping you creating an object
of the other wrapper type using the MS COM handle
(assuming the interface [IDispatch etc] means anything
to that wrapper class)
ilias
<malcol...@jobstream.co.uk> wrote:
>
>"ilias" <use...@abeon.com> wrote in message
>news:bc0521$r5a$1...@newsreader.mailgate.org...
>> >> I think, VOCOM was first.
>> >I _think_ CAs limited classes were first, but I could be wrong.
>>
>> If so, then VOCOM should rely on the design of those.
>What happens once they both exist and evolve separatly
>(as CAs classes and VOCOM have done)
If i understad this right:
Cooperation would be here the optimum.
>> Optimum: replaces completely but in compatible way.
>
>I think I would agree with
>that in the cases
>where the problems with the thing you are replacing
>are not themselves in the design
ok
> then complete compatibility is optimum
ok
>but not always worth it in a cost benefit case
maybe there are cases.
In general, a compatible replacement is easier and thus cheaper. You
can replace step by step, class by class, whilst using the original
parts not replaced yet.
-
Optimum is nearly a must.
If the e.g. the native database library of a product in product A,
vendor X can replace this with an own product.
The design should be as much as possible similar to the existent, thus
a replacement is easy.
>- how much extra would you pay for this ability from a third party?
Much, if it is a critical part of the design.
>What element of VOCOM is giving you a problem as
>an incompatibility between the two?
No element.
I don't know VOCOM. I don't know VO's native COM support.
>(I have code I can use with either for example)
This sounds, that VOCOM do it the optimum way, at least for the
classes you use in the code.
Or couse this compatibility is easily verifiable.
>Equally how much extra would you pay/expect others
>to pay for COMSDK (or VO2.6) for it to be based on
>VOCOM.
I would pay e.g 500 Euro, if i know i got one stable library with
automates the most of my COM tasks, either with code-generators or
with elegant classes.
>
ilias
<malcol...@jobstream.co.uk> wrote:
>
>"ilias" <use...@abeon.com> wrote in message
>news:bc0521$r5a$1...@newsreader.mailgate.org...
>> >> I think, VOCOM was first.
>> >I _think_ CAs limited classes were first, but I could be wrong.
>>
>> If so, then VOCOM should rely on the design of those.
>>
>> Optimum: replaces completely but in compatible way.
>
>From memory given a CA, VOCOM or Vo2ADO COM object
VO2ADO use it's own COM object wrapping classes?
This would be no. 4 .
>there is nothing stopping you creating an object
>of the other wrapper type using the MS COM handle
>(assuming the interface [IDispatch etc] means anything
>to that wrapper class)
Sounds like great flexibility.
I'm not sure if this helps with the Automation-Server-Event-Problem.
-
I have a feeling, that things are very simple.
But i've no time to evaluate all this.
Show must go on.
With COMSDK.
FDW
> COMSDK users have still to purchase VOCOM to use COMSDK
That is NOT true!
Frans
ilias
wrote:
>Ilias,
>
>> COMSDK users have still to purchase VOCOM to use COMSDK
>
>That is NOT true!
Of course this is NOT true.
View the sentence in its context.
>
>Frans
Rod da Silva
For the record, VOCOM was a well tested, shipping product before the
decision to write VO 2.5 (which contains CA's first OLE server support) was
even made. I in fact approached the CA-VO product champion back in 1997 to
see if they would like to bundle VOCOM with VO 2.5 as the COM layer. I
guess the developers decided they would like to implement COM/OLE themselves
(after all its a pretty cool development project for a system developers
<g>). Unfortunately, they dropped the ball IMO, and concentrated on OLE
Automation technologies (which they delivered a year and half later) instead
of first building a solid COM layer in VO, and then building Automation
technologies on top of that (as I have done with VOCOM). To this day if you
go to the System Library in VO and bring up the definition of the IUnknown
class you will see it does _NOT_ include a VTable for the three required
methods of the COM interface: QueryInterface(), AddRef() and Release().
Therefore, as you can see not only could I not "build" on CA's COM layer -
as nothing existed when I wrote VOCOM - but it is still not possible to
build on CA's COM layer even today, because the "real" CA COM layer is in a
C++ DLL that VO developers do not have access to.
As for COMSDK, VO2ADO, ClassMate, and even the articles various authors have
written about creating "client" COM interfaces in VO, to my knowledge they
all use variations on the basic technique of using a dummy VO class VTable
to call a COM interface through a VO class. The technique is well
understood and pretty much used by everyone. The fact that VO has no common
IUnknown that could be inherited from , meant everybody had to provide their
own base IUnknown with the requisite VTable methods mentioned above, I
suspect.
Where VOCOM sets itself apart from these other COM implementations is it
provides the "server" side support of COM. The library can be used to
create any COM object as per the COM specification, using pure VO.
Moreover, a wizard is provided to create a popular class of COM servers
known as an Automation (or ActiveX) COM servers which fully implement the
OLE Automation IDispatch interface. With VOCOM's IDispatch implmenation, I
dare say that exposing a VO class as an Automation Server is made about as
simple as you are going to get. However, you can create any type of COM
server you want (including one that both produces and consumes COM events)
by starting with the wizard code and modifying it for your purpose, or by
writing the server from first principals.. The classes of the library hide
all the complexities of COM server implementations such as providing a
single, shared, generic implementation of IClassFactory, and IUnknown, and
all the object life cycle management (which really get nasty when you start
considering support for callbacks from COM object to another), including the
registering/unrgistering of COM objects with the COM API machinery, and
dealing properly with the ROT (Runtime Object Table), just to name a few.
Moreover, it does all of this without requiring you to look down the VOCOM
COM object in VO's dynamic memory, a feat I am particularly proud of <g>.
I can tell you that there is a world of difference between the client side
and the server side support for COM. The hard bits are in the server side
and to my knowledge VOCOM is still (6 years later) the only generic COM
solution available for VO that fully supports both the client and the server
pieces of the puzzle. VOCOM has not had a major release since its first
release in 1997, and has only seen a couple of minor patches (one to support
in-proc (DLL) servers which the original product did not support) over the
years mainly because the wizard had to be recompiled with newer versions of
VO whenever CA changed the GUI library. The version of VOCOM that comes
with VO 2.6 is the full version of the product (no restrictions) and like
many other VO 3rd party products that ship with VO 2.6, was donated for free
in an effort to support future VO development by adding value to the VO 2.6
release.
The only "new" version of VOCOM is VOCOM+ which I developed over 3 years
ago, and have since made available to developers who wish to purchase a site
license for the product. This product adds some important features to the
core VOCOM product including the ability to create a TypeLib for any VOCOM
COM server, support for advanced COM+ features such as object-pooling, etc.,
and includes full 100% VO source code to the product.
So, hopefully with a complete understanding of the "history" behind COM in
VO you will better understand why the various COM implmentations in VO are
"unsynchronized" to use your term (although I don't understand why you would
expect this from 3rd party vendors).
HTHs,
Rod
Malcolm Gray
> For the record, VOCOM was a well tested, shipping product
> before the decision to write VO 2.5 (which contains CA's first
> OLE server support) was even made.
Malcolm
Geoff Schaller
Amazing.
(...and highly improbable)
"ilias" <use...@abeon.com> wrote in message
news:bbrard$2ed$1...@newsreader.mailgate.org...
Willie Moore
I would like to say for th record that I am a VERY happy VOCOM+ user.! I am
now starting to use VOCOM+ to call ReportPro instead of using the stub
module.
Regards,
Willie
"Rod da Silva" <RodDa...@SoftwareP.com> wrote in message
news:bc2av7$fk$1...@ngspool-d02.news.aol.com...
ilias
you don't have to apologize.
you wrote with precision:
"I _think_ CAs limited classes were first, but I could be wrong."
This in an clearly hypothetical discussion.
ilias
<RodDa...@SoftwareP.com> wrote:
>Ilias, Malcolm
>
>For the record, VOCOM was a well tested, shipping product before the
>decision to write VO 2.5 (which contains CA's first OLE server support) was
>even made. I in fact approached the CA-VO product champion back in 1997 to
>see if they would like to bundle VOCOM with VO 2.5 as the COM layer. I
>guess the developers decided they would like to implement COM/OLE themselves
It seems CA has failed here to:
a) make a good deal with a 3rd party developer
b) at least build compatible library
May you have failed, as you negotiate to hard.
Hypothetical thoughts.
[...]
>of first building a solid COM layer in VO, and then building Automation
>technologies on top of that (as I have done with VOCOM).
=> {For Automation, first build a solid COM layer in VO}
=> {VOCOM has a solid COM layer in VO}
[...]
>Therefore, as you can see not only could I not "build" on CA's COM layer -
>as nothing existed when I wrote VOCOM - but it is still not possible to
>build on CA's COM layer even today, because the "real" CA COM layer is in a
>C++ DLL that VO developers do not have access to.
=> {C++ sourcecode for the unfinished CAVO COM is not available}
[...]
>The fact that VO has no common
>IUnknown that could be inherited from , meant everybody had to provide their
>own base IUnknown with the requisite VTable methods mentioned above, I
>suspect.
{VOCOM has a solid COM layer in VO}
=> everybody could ask to use it or a part of it for compatibility
reasons.
>Where VOCOM sets itself apart from these other COM implementations is it
[...]
>simple as you are going to get.
=> {VOCOM library support creation of any COM object, using pure VO}
=> {VOCOM Supports Automation Server implementation, very simple}
>However, you can create any type of COM
>server you want (including one that both produces and consumes COM events)
>by starting with the wizard code and modifying it for your purpose, or by
>writing the server from first principals..
=> {VOCOM COM Server can produce and consume COM events}
=> {VOCOM wizard code is modifyable}
>The classes of the library hide
[...]
>COM object in VO's dynamic memory, a feat I am particularly proud of <g>.
=> {VOCOM hides all of the COM complexity}
>I can tell you that there is a world of difference between the client side
>and the server side support for COM.
>The hard bits are in the server side
>and to my knowledge VOCOM is still (6 years later) the only generic COM
>solution available for VO that fully supports both the client and the server
>pieces of the puzzle.
=> {COM design, hard bit is the server side}
=> {VOCOM is generic and supports Client and Server side COM}
> VOCOM has not had a major release since its first
[...]
>release.
=> {VOCOM has had only some minor patches since release in 1997}
=> {VOCOM is included in VO 2.6 as full product, donated for free}
>The only "new" version of VOCOM is VOCOM+ which I developed over 3 years
[...]
>and includes full 100% VO source code to the product.
=> {VOCOM+ with full 100% VO source code}
>
>So, hopefully with a complete understanding of the "history" behind COM in
>VO you will better understand why the various COM implmentations in VO are
>"unsynchronized" to use your term
Of course i understand.
The answer is: Egoism.
>(although I don't understand why you would expect this from 3rd party vendors).
To keep their customers happy.
So many code, so little time.
3rd party vendors should cooperate.
at least a little, e.g. in core classes.
>HTHs,
>
>Rod
>
Thank you for your thorough commentary.
This was many information.
I need a little time for ripening them.
-
Could you finally give me an estimation?:
If Someone has the domain-knowledge (COM, COM Events, VOCOM, VO).
How much time would it take to implement "A generic Class-System for
contacting Automation-Server with events" based on VOCOM?
ilias
<ge...@softwareREMobjectives.com.au> wrote:
>So you cannot 'rely' on Fred or Ed
correct.
>to resolve the issues you raise.
e.g.
>Amazing.
>
>(...and highly improbable)
highly. not absolute.
Geoff Schaller
have a distorted and sad view of the world <sigh>.
Ginny Caughey
And both made it to many Blocked Sender lists. <g>
--
Ginny
"Geoff Schaller" <ge...@softwareREMobjectives.com.au> wrote in message
news:YRgFa.419$GU5....@news-server.bigpond.net.au...
Rod da Silva
<<May you have failed, as you negotiate to hard.>>
No, it didn't even get that far. I was in the meeting as one of 5
representitive of the VO User's Groups from all over the world, sent to meet
with Charles Wong/Wang (I can never remember which it is) then CEO of
Computer Associates to try and "convince" him that VO should be developed
further from the VO 2.0 stage. After an very intersting meeting <G>,
Charles decreed that there would be a 2.5 release and the VO product
champion (who was also the head developer/lead architect) was to solicit 3rd
Party products to bundle with it, along with some minor additions (not
unlike VO 2.6). I wrote a proposal to have VOCOM included with VO 2.5 (with
no mention of money) and I never heard back. I am not even sure they read
it. It was no secret that the VO developers had a "Made in Germany"
philosophy so it wasn't surprising to me, even though I knew all of them
very well...(we had a love/hate relationship <g>). To the developer's
credit, they went on to add a great deal of functionality to VO 2.5 (much
more than a "dot" release) over the next 18 months or so, before releaseing
VO 2.5.
>
> Could you finally give me an estimation?:
> If Someone has the domain-knowledge (COM, COM Events, VOCOM, VO).
> How much time would it take to implement "A generic Class-System for
> contacting Automation-Server with events" based on VOCOM?
>
The difficulty here and the reason you and others are having a difficult
time finding a satisfactory solution to "sinking" to events from within VO
is because the OLE Events system has a weak design which has at least a
partial "compile-time" component to them. So it becomes difficult for a
"runtime" product like VOCOM to do much with them in a "generic" way. The
big problem is that to program IConnectionPoint and
IConnectionPointContainer (two otherwise simple COM interfaces) you need to
know (i.e.; hardcode) the IID of the "sink" interface. This requires
"out-of-band" knowledge of the componet you are trying to sink to. In VB
the compiler helps with the "With Events" style of programming. In VOCOM
you have to therefore find out that IID and then programmatically provide a
"sink" implementation specific to that event source interface. I am not
sure how COMSDK does it but I understand there is a manual coding process
there too - I suspect for exactly this reason.
A code generator could be constructed to generate the correct code (based on
say VOCOM) to do this given the TypeLib of the component you want to sink
to, but again this is not a runtime exercise. As for how much effort it
would take someone like me to write a a polished generic code generation
tool, that integrates into the VO IDE to generate a sink class for a
particular OLE Automation event source given a TypeLib....probably 2-3 days.
I have programmed a runtime only implementation of events for VO in the
past, where all events arrived at a single VO call back method identified
only by its DISPID. However, loosing the name of the event and being forced
to identify the event by its DISPID (i.e.; its ordinal number) was
unsatisfactory to me and so I never published this solution.
It is possible to do a completely generic runtime-only solution for OCXs (in
fact VO offers support for this already). For example, VO's WED will
display all of the events (by name) that an OCX supports. OCXs (or ActiveX
Controls if you prefer) are COM servers that source events, and the WED is
dynamically iterating them at runtime for the developer. However, this is
possible with OCXs because the OCX spec provides support for event
negotiation. This support is not provided for lower-level COM servers.
Having said all of that, Microsoft is steadily moving away from the OLE
Events style of events. The design has proven rigid over the years (for the
very reasons I have stated), and has been replaced with more "generic" event
systems such as COM+ loosely coupled events, and more recently, the superb
.NET event system. Unfortunately, that doesn't help us with legacy code.
So if you want a VO solution you have a few choices, some are:
1) Use COMSDK
2) Go look up the IConnectionPoint and IConnectionPointContainer definitions
on MSDN (The Inside OLE 2.0 book which is part of the MSDN library has an
entire chapter describing OLE events) and study them, then find out what IID
your particular event source interface has, then study the IAnimal sample
that comes with VOCOM, then write a custom solution in VOCOM and learn
something new!
3) Pay someone like me to do a generic solution for you so you do not have
to bother with the gory details, and then donate it to the rest of the VO
community out of the goodness of your heart.
Then again you can always switch to VB <g>.
Rod
Gary Stark
Ginny Caughey wrote:
> Geoff,
>
> And both made it to many Blocked Sender lists. <g>
Very quickly in one case. :)
--
g.
Gary Stark
gst...@RedbacksWeb.com
http://RedbacksWeb.com
Ginny Caughey
;-)
--
Ginny
"Gary Stark" <3061...@RedbacksWeb.com> wrote in message
news:3EE67213...@RedbacksWeb.com...
ilias
<RodDa...@SoftwareP.com> wrote:
>Ilias
>
><<May you have failed, as you negotiate to hard.>>
>
>No, it didn't even get that far. I was in the meeting as one of 5
[...}
>Charles decreed that there would be a 2.5 release and the VO product
>champion (who was also the head developer/lead architect)
VO product champion, who was this?
Isn't the usual word "manager"?
>was to solicit 3rd
>Party products to bundle with it, along with some minor additions (not
[...]
>VO 2.5.
=> {no negotioations from CA, to integrate VOCOM}
=> {VO developers, Made in Germany philosophy}
>> Could you finally give me an estimation?:
>> If Someone has the domain-knowledge (COM, COM Events, VOCOM, VO).
>> How much time would it take to implement "A generic Class-System for
>> contacting Automation-Server with events" based on VOCOM?
>>
>
>The difficulty here and the reason you and others are having a difficult
[...]
>there too - I suspect for exactly this reason.
=> {generic (runtime) implementation of COM Events impossible/very
difficult}
>A code generator could be constructed to generate the correct code (based on
[...]
>particular OLE Automation event source given a TypeLib....probably 2-3 days.
=> {code generator: estimated time 2-3 days, (person with full
domain-knowledge)}
>I have programmed a runtime only implementation of events for VO in the
>past, where all events arrived at a single VO call back method identified
>only by its DISPID. However, loosing the name of the event and being forced
>to identify the event by its DISPID (i.e.; its ordinal number) was
>unsatisfactory to me and so I never published this solution.
Sounds very interesting.
Sourcecode available on request?
>It is possible to do a completely generic runtime-only solution for OCXs (in
[...]
>negotiation. This support is not provided for lower-level COM servers.
=> {for OCX, fully generic runtime-solution possible, due to
event-negotiation support}
>Having said all of that, Microsoft is steadily moving away from the OLE
>Events style of events. The design has proven rigid over the years (for the
>very reasons I have stated), and has been replaced with more "generic" event
>systems such as COM+ loosely coupled events, and more recently, the superb
>.NET event system. Unfortunately, that doesn't help us with legacy code.
=> {MS moves away from COM Events, but still many legacy code}
Many(!) legacy code.
>So if you want a VO solution you have a few choices, some are:
>
>1) Use COMSDK
My current status.
>2) Go look up the IConnectionPoint and IConnectionPointContainer definitions
>on MSDN (The Inside OLE 2.0 book which is part of the MSDN library has an
>entire chapter describing OLE events) and study them, then find out what IID
>your particular event source interface has, then study the IAnimal sample
>that comes with VOCOM, then write a custom solution in VOCOM and learn
>something new!
{code generator: estimated time 2-3 days, (person with full
domain-knowledge)}
Thus you should be able to do an "IAnimal Bark-Back" example in one
day.
-
Alternative process:
Gain domain-knowledge from an implementaion e.g.
http://www.techvanguards.com/products/eventsinkimp/
and implement it in VOCOM.
>3) Pay someone like me to do a generic solution for you so you do not have
>to bother with the gory details, and then donate it to the rest of the VO
>community out of the goodness of your heart.
What about an exchange?
2-3 days deep evaluation of CULE.NET.
Please use email to send me your offer.
>Then again you can always switch to VB <g>.
Yes, maybe the next decade.
>
>Rod
>
Karl-Heinz Rauscher
>> [Rod]
>>3) Pay someone like me to do a generic solution for you so you do not have
>>to bother with the gory details, and then donate it to the rest of the VO
>>community out of the goodness of your heart.
> [Ilias]
> What about an exchange?
> 2-3 days deep evaluation of CULE.NET.
mmh, a interesting point of view <g> ; just starting to count my
- until now - invested beta days .....
--
regards
Karl-Heinz
CULE - the easier C#, the smarter VO
Rod da Silva
>> [Rod]
>>3) Pay someone like me to do a generic solution for you so you do not have
>>to bother with the gory details, and then donate it to the rest of the VO
>>community out of the goodness of your heart.
> [Ilias]
> What about an exchange?
> 2-3 days deep evaluation of CULE.NET.
>
> mmh, a interesting point of view <g> ; just starting to count my
> - until now - invested beta days .....
To compensate you adequately for the amount of time you have invested in
CULE.NET Beta testing for me, I would have to write you something
considerably more complex then a VO IDE subsystem to generate COM event
sinking code.... It would have to be something much more signifiacnt...such
as a compiler or something...<g>.
Seriously, your dedication to the CULE project has been awesome. CULE would
be nowhere near as far along as it is without your constant support over the
last year. Its the dedication of people like you that keep me going on this
project when I start feeling like I never want to see another parser
production rule again.
Thank-you.
(Now get back to testing!)
Rod
Now get back to testing CULE!
Rod
Rod da Silva
>
> VO product champion, who was this?
>
Names aren't important.
>
> Thus you should be able to do an "IAnimal Bark-Back" example in one
> day.
Probably half a day.
>
> -
>
> Alternative process:
> Gain domain-knowledge from an implementaion e.g.
>
> http://www.techvanguards.com/products/eventsinkimp/
>
> and implement it in VOCOM.
Good idea.
>
> >3) Pay someone like me to do a generic solution for you so you do not
have
> >to bother with the gory details, and then donate it to the rest of the VO
> >community out of the goodness of your heart.
>
> What about an exchange?
>
> 2-3 days deep evaluation of CULE.NET.
>
You want me to do really difficult low-level COM work for you in VO and in
return you get to have fun and play and learning with the exciting new .NET
language CULE? This hardly seems fair <g>.
Seriously, I will try and dig up one of the COM event sinking
implementations I have written in the past as a reference for you (give me a
couple of days to search my archives). Erik Wynn, a name I haven't seen
around these parts in years, did an excellent 90 minute session at one of
the many VO converences he attended some years back (complete with a
presentation paper and all sources) on how to program COM Event Sinks with
VOCOM, specifically showing how to implement two-way conversations with
IConnectionPoint and IConnectionPointContainer between Event Sinks and
Sources. I might even have a copy of that code somewhere as I helped him
with some of it, but no promises - it was a long time ago. I am sure he
wouldn't mind me passing it along to you if I can find it. If I find it I
will post it to my web site for download and post the URL here.
HTHs,
Rod
ilias
<RodDa...@SoftwareP.com> wrote:
>Ilias
>
>>
>> VO product champion, who was this?
>>
>
>Names aren't important.
But you mention one of the 2 persons by name (Charles Wong/Wang):
"
Charles decreed that there would be a 2.5 release and the VO product
champion (who was also the head developer/lead architect)
"
I think it is friendly against the readers to write the name, thus
they know who is (or was) the head developer/lead architect of VO.
Especially as this is an VO-Group.
(i try a quick search, but i fail)
>> Thus you should be able to do an "IAnimal Bark-Back" example in one
>> day.
>
>Probably half a day.
That's quick!
What i don't understand:
It looks to me that you contribute very much to VO / VO-community.
And many people have problems with events.
And you need very less time to do this task.
Then why until now you haven't done this (create an example) and
included this to the VOCOM examples (free product included with VO)?
And perhaps additionally an codegenerator for the IDE (your
estimation: 2-3 days) and include it to VOCOM+ ( full product with
COM+ support and sourcecode, site licence)?
By the way: what is the price of VOCOM+
>> Alternative process:
>> Gain domain-knowledge from an implementaion e.g.
>>
>> http://www.techvanguards.com/products/eventsinkimp/
>>
>> and implement it in VOCOM.
>
>Good idea.
It comes with source code.
Someone familar with Delphi and VO could modify it to produce VO code
based on VOCOM.
>> >3) Pay someone like me to do a generic solution for you so you do not
>> >have
>> >to bother with the gory details, and then donate it to the rest of the VO
>> >community out of the goodness of your heart.
>>
>> What about an exchange?
>>
>> 2-3 days deep evaluation of CULE.NET.
>>
>
>You want me to do really difficult low-level COM work for you in VO and in
>return you get to have fun and play and learning with the exciting new .NET
>language CULE? This hardly seems fair <g>.
But it is!
I meant a really difficult indeep multiple context evaluation, which
means for me "stop to live for those 2-3 days".
>
>Seriously, I will try and dig up one of the COM event sinking
[...]
>will post it to my web site for download and post the URL here.
Very kindly.
What about the "runtime only implementation of events" you've
mentioned?
If there is any source available?
>
>HTHs,
>
>Rod
>
Stephen Quinn
> I think it is friendly against the readers to write the name, thus
> they know who is (or was) the head developer/lead architect of VO.
Charles Wang was the CEO/HeadHoncho/maybe even part owner of CA not a developer of any product
AFAIK.
> >> VO product champion, who was this?
There were a couple over the years, most if not ALL CA products had Champions, no idea if that
system/naming is still in vogue in CA though.
As to who they were it doesn't matter, AFAIK they no longer work for CA.
--
HTH
Steve Quinn
Karl-Heinz Rauscher
>> It would have to be something much more signifiacnt...such
>> as a compiler or something...<g>.
mmmh , "something" like shares , or some stock options would be of
interest .. <bg>
To be serious. it愀 *you* and *your* team that does the impressive work.
You愉e always able to give me an answer if i run in troubles, but you
can愒 count on me if you run in troubles <g>.
BTW. in another thread you mentioned that the next build will include
NoMethod, NoIVarGet etc. support. sounds great !
Mark L. Cooper
From memory (not the best in the world<g>):
Charles Wang is the founder/CEO of CA. After starting CA, he fairly quickly
merged with another company, doubling the size of his business. After that,
much of CA's growth came from the acquisition of smaller companies.
I'm drawing a blank on the original name (something nautical, or maybe
Aspen??), but VO was already on the drawing board when CA acquired
Nantucket.
Mark
--
Mark L. Cooper
Columbus, Ohio USA
Rod da Silva
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>> Thus you should be able to do an "IAnimal Bark-Back" example in one
>> day.
>
>Probably half a day.
That's quick!
What i don't understand:
It looks to me that you contribute very much to VO / VO-community.
And many people have problems with events.
And you need very less time to do this task.
Then why until now you haven't done this (create an example) and
included this to the VOCOM examples (free product included with VO)?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
People will continue to have problems with COM Events if they don't learn
COM, because it is very hard to make them "easy" without compiler/tool
support. Its not that COM is hard (okay it is <g>) but it is just
programming. My solution for COM for VO was to create a library that would
let those interested in working with COM to do just that without the "sting"
of C++ getting in your way. I published VOCOM to the sound of a pin
dropping - at least with respect to its COM support. Nobody understood the
product (most still don't). Everybody went on and on about how easy it was
to build an ActiveX Server with the product (that was pretty novel even for
advanced VO'ers back in 1996-97 and something VO sorely needed in comparison
to VC++ and VB) but virtually nobody took the time to understand the code
that the wizard generated - that is understand what the tool and the library
it is based on does. The library is fully documented. But like all API
documentation, unless you understand the big picture of what you are suppose
to do with the APIs the documentation will make little sense.
One of the samples that comes with VOCOM is IAnimal. An admittedly
contrived sample but one that is heavily commented and demonstrates how to
define and work with a COM interface in VOCOM - one of the atomic actions in
COM programming. I doubt seriously if anyone every tried to do anything
based on that sample. Its not because the sample sucks (at least I don't
think so <g>). Its because as application developers, when you look at that
sample your first reaction is "whoa! what the h#ell is this!" and tune out.
That's the effect COM has on people. (A couple of years ago I experienced
this same feeling when I tried my hand at some kernel-level development. It
was like scuba diving for the first time....a completely different world!
Every professional developer should go scuba diving regularly IMO...its how
you grow as a developer.)
So yes sure I could write a ton of little COM samples to show people how to
do one thing or another, but in the end they will be COM samples and people
will still say "whoa!". So rather than give them fish, I will provide
everything they need to fish for themselves. I stop short of actually
"teaching" them to fish, though. This they must teach themselves. And that
requires motivation, regardless of whether its the "I have a project I have
to get done" or the "hey I wonder how all that works" kind.
<<And perhaps additionally an codegenerator for the IDE (your
estimation: 2-3 days) and include it to VOCOM+ ( full product with
COM+ support and sourcecode, site licence)?
>>
That's a good idea. And while I am at it I could add a few more features to
the wizard such as support for:
1) Creating COM+ components as Windows Services
2) Creating SOAP enabled VOCOM objects
3) Creating VO Web Services
4) etc.,
Problem is that it would take me a few months to write, test, document, and
publish this stuff to the professional level that I demand of myself, and
then I would be looking at selling it to an audience that largely doesn't
need this functionality (translated - sell only a few dozen copies
initially). As has been stated here by several prominent VO developers
recently, many of the VO users just don't need COM/COM+/WebServices etc.,
(until of course they need them - if you know what I mean).
I had the exact same problem when I first came out with VOCOM. The VO
community just didn't initially need what I was selling (or at least they
didn't know they needed it <g>). I remember approaching a leading
distributor in the VO community in the fall of 1997 and asking his advice on
what I should sell VOCOM for and whether he would distribute it for me (I
was a programmer not a software distributor after all). He told me that he
didn't think I would sell many and I should probably set the price high and
go after a specialty market, and that VOCOM wasn't a fit for him. I then
decided to sell it directly myself and had to go and set myself up with the
ability to take credit card orders over the phone, and all that stuff just
to sell the product- what a pain. A year later after VOCOM had sold a few
hundred copies and was getting good word of mouth reviews, that same
distributor wanted to know why I wouldn't give him a copy or two of VOCOM to
sell as he was getting requests for it. Eventually I let him distribute the
product, but I made him commit to a large initial order as penance for his
sins <g>.
The point of this story is at the time I approached him he didn't understand
the product. I am not blaming him (I wasn't upset or anything and actually
considered taking his advice as I respected his opinion), it was just the
way it was. COM+ is no different. Few here really understand COM let alone
what COM+ adds to the mix. So you don't need VOCOM+ until you need it!
Likewise people won't need WebServices until they need them. Its the nature
of the beast. Who's got time for playing/learning for playing/learning
sake?
So I could take the "build it and they will come" attitude like I did with
VOCOM. But my business sense tells me this isn't prudent. Instead I am
busy developing other "field of dreams" projects which I believe will
ultimately have a much broader appeal then beefing up the already
underutilized COM support of VO with a new and improved VOCOM++ or whatever
for an audience that, in large, doesn't need it. Besides, VO is actively
being developed again by Brian and company so I believe there is a certain
onus on him to add "forward thinking" (or given the timeframe - "catch-up")
product innovations such as support for Web Services to the product. But
Brian will ultimately add features to his product that will give him in his
estimation the greatest return on investment. I don't here very many people
asking for VO WebService support in this forum even though they are all the
rage in the halls of Microsoft and IBM. So does it make sense for him (or
anyone else for that matter) to invest in adding it to the product?
Its a fine line when you are a development product/tools vendor. You want
to give the people what they are asking for and yet you owe it to them to
innovate and think ahead and give them what they don't even know they need
yet. (Remeber no one asked for codeblocks or TBrowse when Clipper 5.0 came
out). The former means you are behind the times since if your customers are
asking for it in mass, whether they actually need it or just because a
competing product has it, then it is arguably a little late and you are play
the catch-up "me too" game. The latter is of course risky as it requires
you to "see the future" and bet on which "unproven" technology will be in
vogue next year.
I think it would be interesting to start a thread to find out "what VO
developers want" in the next major version of VO. What would be amusing to
me is to find out, of the features being asked for how many people want them
because a) they really need them or b) they don't personally need them but
feel they need to be in the product for the product to move forward and be
taken seriously.
To be brutally honest I don't envy Brian's position at all. Given my
perception of how the majority of VO developers use the product, there would
seem very little technical reason to rev VO to another major version (i.e.;
3.0). The 10 year old product is already very mature and already does the
majority of what most people in its user base needs it to do. But to stop
developing the product is the kiss of death for a product and no one here
wants to see that happen. So Brian either has to scrape the bottom of the
barrel and think of more things to add to an already very mature Win32
application development tool to justify another release, or he has to shake
things up and take VO in a different direction such as .NET (or Linux)
support. The irony (which is definitely not lost on me) is that most people
here don't need/want .NET! And those that do have already established that
fact and moved to C# for the most part. So in many respects a VO.NET is
again a leap of faith for Brian - a huge risk with very little in the way of
guarantees.
The truth of the matter is that as a whole, VO developers are not early
adopters of technology. They complain that their vendor does not keep up
with the times, but they themselves are behind the times (this is not a slam
just an observation). They need the technology when they need it and
complain when its not there. VO developers are not tech driven IMO, but
rather business/customer driven - and it shows in their choice of
development tool. For a development product vendor to keep up with the
times means not only having a technology driven audience, but necessarily
raising the price of the product to cover the cost of bleeding edge
development. Even discussing the concept of raising the price of the
product rubs many in this forum the wrong way. Why? Because most aren't
doing leading edge work and therefore aren't charging their customers
leading edge prices which means they don't have the money to afford a
leading edge product or to invest in the time to learn the technologies they
are based on. Its a vicious circle and I don't know the solution.
Add to this the VO user demographic. I have no data on this but just from
my own experience and having met a ton of VO developers over the years where
I have always been one of the younger ones, the average VO user is over 40
in my estimate (I am not as young as I use to be <g>). As developers that's
old...really old! What goes hand-in-hand with this is the amount of new VO
development occuring is necessarily drop. Lets face it. We don't have the
energy we once had and code cutting doesn't have the allure it once did.
Its work, and it doesn't pay the bills (its a cost center not profit center
for the most part). So I am willing to bet the majority of VO developers
use VO to maintain their existing systems. They want VO to be around for a
long long time, not because they are waiting with baited breath like a 22
year-old propeller head for the feature list of VO 3.0, but rather because
the main software their business sells is written in it/depends on it. Of
this profile, how many are actually thinking about porting this system to a
newer more modern platform/language versus hoping to just be able to
maintain the system for a few more year (after all retirement isn't far off
<g>) in the popular Win32 environment? My point is that development for
development sake is not the mantra of the average VO developer anymore (and
hasn't been for quite some time). Without some new young blood in
community - people who are excited about the language/product and write
software just because they can - to drive it forward technologically
speaking, VO's user base will continue to shrink IMO if only by natural
attrition.
But its not all doom and gloom. All things considered, VO is awesome.
Brian just has to figure out a way to let new blood know this. I think he
has to reinvent the product somehow. Its a marketing problem as much as
technology/development problem. But the key is getting the young people.
Because young people tend to grow up, get jobs and become programming
department heads for companies, and ultimately have some influence in the
languages/development products they use. I believe the new VO strategy has
to be a long term one. Build a new community from the ground up. This will
take time and a methodical plan. How you fund this is a big question. The
only thing that is not in question, is the technology on which to base this
plan. VO is a solid mature asset and Brian's development team is
world-class. If anyone can do it he can. Brian needs all of our support.
Not just to purchase the next releases of VO (although he needs that too
<g>), but to go back to school and modernize our skill set. Create demand
for new technologies rather than waiting for them to be needed. If you get
excited about new technology (and there is lots to be excited about) this
will translate into a rejuvenated community atmosphere which will spill over
into VO journals, conferences, plans to rewrite systems which in turn means
hiring new young (cheap) developers and creating software update revenue.
The whole community needs a shake up IMO and it has to come from within, if
the community as a whole is going to grow.
...Wow...that's the last time I try and catch up on a weeks worth of
Flintstone chewable vitamins all at once.... I got a little carried away I
guess...sorry for the complete OT ramblings...
Anyway Ilias back to your question. The short answer <g> is no I won't be
investing anymore time in the VOCOM line of products without having that
time compensated by a paying customer. In fact that's how type library
support got into VOCOM+ - a customer needed it and paid me to write it for
him at a negotiated lower price than I would normally charge in order for me
to keep the rights to the software. This is just a business decision. I am
satisfied that VOCOM is rich enough to allow any motivated developer to
create their own COM solutions, regardless of the complexity. Reset assured
my support for the VO community manifests itself in other ways these days.
>> What does VOCOM+ cost?
$800 U.S. for a _site_ license and all source code.
> >>
> >
> >You want me to do really difficult low-level COM work for you in VO and
in
> >return you get to have fun and play and learning with the exciting new
.NET
> >language CULE? This hardly seems fair <g>.
>
> But it is!
>
> I meant a really difficult indeep multiple context evaluation, which
> means for me "stop to live for those 2-3 days".
I think if you take those 2-3 days and apply them to your COM Events sinking
issue you will solve your problem. Then maybe you will share it with the VO
community on your own. As I said I will try and find you all relevant VOCOM
code I have on the subject, but you must give me a few days as I am out of
the office for a while.
The CULE.NET beta test team would value your participation (we don't even
ask you to stop living <g>), but it will have to come from your own free
will...
HTHs, (and with apologies for the long post)
Rod
Phil McGuinness
So much said and I am sure I agree on just about every word and observation.
Let me comment on a couple of things because the overall context of your
thoughts will spawn many threads for various reasons.
snip[ The truth of the matter is that as a whole, VO developers are not
early adopters of technology.]
I would have to agree.. You mention age of both VO and the users but I think
a lot has to do with the path these developers have travelled verse some of
the "propeller heads".. Different mind set and market I think.
===
snip[ They complain that their vendor does not keep up with the times, but
they themselves are behind the times (this is not a slam just an
observation). ]
Yes.. I would agree.. You don't know what you really want until somebody
or the market says I want one just like this but pink and we say no
worries... Shit how can I do this.. get on the web .. get into the Group..
somebody will know.. and the great thing is the VO has enough depth still
to solve almost all problems.
===
snip[ They need the technology when they need it and complain when its not
there. VO developers are not tech driven IMO, but rather business/customer
driven - and it shows in their choice of development tool. ]
So true... but that is because this where our income is derived from.. we
are at the coal face and if we fail we wear the cost and support calls.
Most here are small vertical market developers and do not have economy scale
to attend regular conferences or training too many extra VO'ers.
===
snip[ I think it would be interesting to start a thread to find out "what VO
developers want" in the next major version of VO. ]
For me extensibility... and more speed .. better docs and Open the market up
to VO using the forces in the market that are winning.. I read today there
are currently 80,000 open source projects run today in the world. This means
there are lot of people looking for something that the main stream providors
are not providing. A lot want a place to hang their hat like a lot of us
have done with VO todate. Essentially I am happy with VO now.. but that is
because somebody or the market has not yet dragged me into Services or XML
or DHTML or SOAP or whatever is that "next thing". There is a lot to be
said about the Linux comment as well if we are planning a few years out...
it is going to be a very changeable market over the next 3-5 years.
===
snip[ But the key is getting the young people. Because young people tend to
grow up, get jobs and become programming department heads for companies, and
ultimately have some influence in the languages/development products they
use. I believe the new VO strategy has to be a long term one. ]
Yep.. this is the key.. otherwise you are never going to get VO into the
mainstream.. and it is going to be tough because the commercial players are
deadly and have the money and resources and the "mind control" at this stage
anyway. Somehow we need to piggyback or be associated with a winning
product or area of the market.. PHP and mySQL grew together yet it was
collaboration rather than co-marketing.
===
snip[ The whole community needs a shake up IMO and it has to come from
within, if the community as a whole is going to grow. ]
Yes unfortunately.. and VO2.7 might just attract enough new bodies to make
it start to happen.
===
Phil McGuinness - Sherlock Software
--------------
Gary Stark
Getting closer ...
"Mark L. Cooper" wrote:
> Steve,
>
> From memory (not the best in the world<g>):
>
> Charles Wang is the founder/CEO of CA. After starting CA, he fairly quickly
> merged with another company, doubling the size of his business. After that,
> much of CA's growth came from the acquisition of smaller companies.
Actually, Charles IIRC started (or was involved with/in) a different
corporation, and acquired CA which actually was a European organisation at that
time. I probably still have all of this around here somewhere ...
> I'm drawing a blank on the original name (something nautical, or maybe
> Aspen??), but VO was already on the drawing board when CA acquired
> Nantucket.
Aspen was the original name for VO, which you correctly point out was already
being developed by Nantucket when CA acquired them. It was all being done in
Germany, and CA thought it could use the technology that was being developed.
Rod da Silva
<<Yes.. I would agree.. You don't know what you really want until somebody
or the market says I want one just like this but pink and we say no
worries... Shit how can I do this.. get on the web .. get into the Group..
somebody will know.. and the great thing is the VO has enough depth still
to solve almost all problems.
>>
Bingo. I hate that you can say in one paragraph what takes me pages <g>!!
In a nutshell the VO users are reactionary. They aren't a proactive early
adopters. This isn't a negative thing. Its just a consequence of the
"different mindset and market" you mentioned. They are customer driven.
But VO keeps rolling because of its shear depth as a core level development
product. Its amazing to think of the money that was put behind products
that were once quite popular like SmallTalk and PowerBuilder to name two.
Yet its the product that was never marketed - VO - that is still chugging
along....
Rod
Phil McGuinness
I guess the reason I have been so adamant about Open Source is I see an
energy that is not dictated to my corporate strategies and mind control but
solving a problem and seeing a need and getting the energy from like mind
developers to do stuff.. However I see their roles clearly as well.. There
is a need for grass roots and open and the fully blown commercial end of
town. Maybe than fun and drive that we enjoyed in "code cutting" might
return when we do not see each week and month in this futile race to
obsolesce all the time.
I mean if we were home builders we would clear the land, build the house and
knock it down and start again before the tenants moved in.. not because we
wanted to but because "the market" dictates it.
Look at CULE development from another perspective. Without a doubt you have
the talent to do some very serious coding.. I get a headache with this
stuff. I mean you really get to the nuts and bolts and infact go out and
make the Die, cast it and hand craft the tools to make the nuts and bolts.
I hope you efforts are well rewarded.
I know you have the vision to look ahead and build what you think we will
need and we should have in the tool kit and what you will need tomorrow just
to making a living.. It must be frustrating to know what your about and see
the greater VO community unfortunately today at least, on slight different
time scale and business philosophy.
Phil McGuinness - Sherlock Software
--------
"Rod da Silva" <RodDa...@SoftwareP.com> wrote in message
news:bcadpu$pq2$1...@ngspool-d02.news.aol.com...
> Phil
Ginny Caughey
There is indeed a lot of energy in Open Source, and I sometimes wonder where
those developers find the time to donate their talents. I suspect that most Open
Source developers are not owners of small vertical software companies <g>, and
this is one of the problems for VO. Many VO developers don't have a regular
salary coming in where somebody else sells their work and sees to it that the
money is collected, so in their "spare" time they have to sell, support, and run
a business as well as writing software. That doesn't leave a lot of time to work
on an Open Source project.
--
Ginny
"Phil McGuinness" <hey...@sherlock.com.au> wrote in message
news:bcafas$gogih$1...@ID-88745.news.dfncis.de...
Ed Richard
> HTHs, (and with apologies for the long post)
Thanks you very much for sharing your mindset with us. I've read the post
three times now, and I have to agree with you on everything. I whish I could
express myself like this.
I'm glad you're reading this NG and are contributing whenever appropriate.
As for other developments, I've been watching products that provide
DBF-access in .net for a while now and although a few, like VistaSoftware
have made some noise nothing seems to be really working. Let alone offer
true Clipper and VO compatibility.
Do you feel this is an area Brian should get into based on the DBFCDX-code?
Ed
Phil McGuinness
their talents. ]
Some of it is excellent stuff..
I think a lot get stifled in working a full time job having to use VB or
something and want to use other languages. I also think when 100+ people
all work on a piece of something they lift each other.
I think the belonging and ownership are human traits and basically it was
what powers the Free enterprise system... beside Money and Lawyers.<G>
Phil McGuinness - Sherlock Software
----------
"Ginny Caughey" <ginny....@wasteworks.com> wrote in message
news:bcag4a$gl401$1...@ID-144704.news.dfncis.de...
Rod da Silva
<<It must be frustrating to know what your about and see
the greater VO community unfortunately today at least, on slight different
time scale and business philosophy.
>>
Yes it is. But I do not look at the VO community as my end market. I want
the new blood I spoke of earlier that .NET in general will be bring over the
next several years IMHO. So I am building a language to address that
market, first and foremost. VO developers that are going through a mid-life
crisis and are debating between a) having an affair, b) buying a sports car
or c) jumping to a new development language/platform will also be interested
in checking CULE out <g>.
Now that's not to say that I do not try to cater to existing "conservative"
VO developers. One has only to look at the depths I have gone to make the
CULE language as compataible to VO as I can be to understand this.
What I know is this. I have a lot of friends in this community whom I have
had the pleasure of meeting over the past decade, and many of whom I have
not. For the most part they wish me well on the CULE project. That's a
nice feeling. Some will even help test CULE without having a production
need for such a tool. I hope some will buy it when its ready. In general
the VO community is a big source of inspiration to me - especially on such a
long project as this.
I see my only job as ensuring there is a .NET solution for them in 2 years
time when they find they "need" one. In the meantime, I must pursue other
less "entrenched" users as well. There is room for everyone. I can only
hope somebody shows when I throw the big party <G>.
Rod
Phil McGuinness
As long as I can bring the sport car with the girl I am having an affair
with a new development language. <G>
Phil McGuinness - Sherlock Software
----
"Rod da Silva" <RodDa...@SoftwareP.com> wrote in message
news:bcajpi$7lh$1...@ngspool-d02.news.aol.com...
Rod da Silva
<<As for other developments, I've been watching products that provide
DBF-access in .net for a while now and although a few, like VistaSoftware
have made some noise nothing seems to be really working. Let alone offer
true Clipper and VO compatibility.>>
<<> Do you feel this is an area Brian should get into based on the
DBFCDX-code?
Well, lets look at this from a business man's point of view:
Premise: There is no good "managed code" solution for DBFCDX support
Market: Those DBFCDX users that want to do development in .NET.
Competition: ??
Development Costs: 1.5 man-month to port C source to DBFCDX to .NET
Framework using CULE (or C# <g>)., 2.5 months to test and document
Time to Market: 4 months after testing and documentation
Impact on Existing Development: ??
Distribution: Sell direct as a 3rd party product, license to other
.NET language vendors as add-in
Revenue per Unit Sold: ??
How Much Does CA Get of the Profits: ??
The big question is the "Market" IMO. How many people make up the target
market? Judging from this forum not many. But maybe looking at the FoxPro
group and you have a bigger market. Do they need DBFCDX support as well
(there are so many other FoxPro file formats that I have lost track if
DBFCDX is even relevant to them any more)? Thinking a little outside the
box is to realize that a 3rd party .NET product with no GUI and based solely
on CLI subset of the .NET Framework will work in other .NET Framework
environments. So purpose Mono becomes a potential market place. But how
many Linux people want (or even know about) DBFCDX?
The next big question is if he does it, what can't he do. I.e. what's the
impact to his other development. Potentially nothing if he farms the job
out to someone who knows both C/C++ and a .NET language. But development
time == money which he could be putting towards VO 2.7 or VO 3.0.
Even though the project could be developed quickly, it probably couldn't
sell for very much and then CA might get a piece of the action - but I think
Brian probably controls the DBFCDX driver code 100%.
There is a lot for him to consider on even a small project like this, let
along a massive project like a VO.NET. Lots of risk and lots of potential
gain.
So would you do DBFCDX.NET if you were Brian? <g> Would you do a VO.NET?
Let me throw another thought out there. Lets jump ahead 3 years and the
.NET market begins to shake out and the only major language vendors still
standing are:
1) Microsoft (VB.NET, JScript.NET, C#, J#, F#, G#, etc.,,,)
2) Borland (Delphi.NET - in development at the moment)
3) Brian (VO.NET )
Now a big company comes along and decides it strategic for them to be a
language tools development company on the .NET platform in the next 12
months. What are they going to do? They can't come to the .NET market with
a C or Java like language as MS has the market sown up (this by the way is a
small piece of brillance on the part of MS). They could build their own
language and market it like new, but its hard to launch a new langauge.
Another option is to acquire an elegant proven language that has a small but
vocal user base and then improve it and market the sh&t out of it.
There are lots of ways to the end game. Regardless of the path you take
perseverance is a necessary (but rarely sufficient) charcteristic to getting
there.
But this is all hypothetical of course since there currently is no VO-like
solution for .NET available - at least not yet.
Rod
Geoff Schaller
most Open
> Source developers are not owners of small vertical software companies <g>,
and
Ain't THAT the truth! <g>
Rod da Silva
<<I think a lot get stifled in working a full time job having to use VB or
something and want to use other languages. I also think when 100+ people
all work on a piece of something they lift each other.
I think the belonging and ownership are human traits and basically it was
what powers the Free enterprise system.
>>
Well said.
Rod
Willie Moore
I must admit that I bought VOCOM when it came out and put it on the shelf
for a year or so. Then I needed it. Since then, I have developed much less
GUI and much more middle layer code. I could not have done it without VOCOM!
I still do not do a lot of "complex" things with COM but I like the fact
that I can create my VOCOM objects and use them the same way in a web app or
a GUI app. It has made my programming like much easier. With the typelibrary
support in VOCOM+, the vb programmers I have to interface with have finally
stopped complaining!!!
Regards,
Willie
ilias
<RodDa...@SoftwareP.com> wrote:
>Ilias
>
><<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>> Thus you should be able to do an "IAnimal Bark-Back" example in one
>>> day.
>>
>>Probably half a day.
>
>That's quick!
>
>What i don't understand:
>It looks to me that you contribute very much to VO / VO-community.
>And many people have problems with events.
>And you need very less time to do this task.
>
>Then why until now you haven't done this (create an example) and
>included this to the VOCOM examples (free product included with VO)?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>
[...]
><<And perhaps additionally an codegenerator for the IDE (your
>estimation: 2-3 days) and include it to VOCOM+ ( full product with
>COM+ support and sourcecode, site licence)?
>>>
>That's a good idea. And while I am at it I could add a few more features to
>the wizard such as support for:
>
>1) Creating COM+ components as Windows Services
>2) Creating SOAP enabled VOCOM objects
>3) Creating VO Web Services
>4) etc.,
Of course not. "Automation-Server-Events" is the topic.
I meant only what we discussed: 2-3 days for the codegenerator.
[...]
>...Wow...that's the last time I try and catch up on a weeks worth of
>Flintstone chewable vitamins all at once.... I got a little carried away I
>guess...sorry for the complete OT ramblings...
>
>Anyway Ilias back to your question. The short answer <g> is no I won't be
>investing anymore time in the VOCOM line of products without having that
>time compensated by a paying customer.
Your answer starts with: "No i won't be investing anymore time..."
[refers to future]
But my question started with: "Why until now..."
[refers to past]]
>In fact that's how type library
>support got into VOCOM+ - a customer needed it and paid me to write it for
>him at a negotiated lower price than I would normally charge in order for me
>to keep the rights to the software.
[Remark: I'm not sure, if this is the "fairplay" solution, as this
developement raises incoming from VOCOM+ sales (as some other
customers will buy it for exact this reason).]
-
I've written [maybe not in an clear context]:
"Please use email to send me your offer."
This is still valid: please send me an offer via email.
>This is just a business decision. I am
>satisfied that VOCOM is rich enough to allow any motivated developer to
>create their own COM solutions, regardless of the complexity. Reset assured
>my support for the VO community manifests itself in other ways these days.
I understand some of your thoughts in your answer (sorry for not
quoting exactly, processing-overload).
A library-product should encapsulate the domain-knowledge (e.g. API
etc.) fully, thus the developer does not need to go into the details.
On the other hand, the product should provide if possible all details
of the implementation (source-code, domain-knowledge) if an developer
wants to modify / correct / fully understand the code.
Finally it should give some extension domain-knowledge, to give the
devolopers a starting-point and a motivation to extend the product
(here: adding Events to VOCOM).
The starting-point is the barrier. If you had included from the early
beginning an example with Events (or even a textual description of the
process), someone had maybe build out of that a solution, perhaps with
an IDE-Tool, too.
Even if you are right in your saying, that most customers don't look
at the examples, you should provide them for those few which go the
right way.
>>> What does VOCOM+ cost?
>
>$800 U.S. for a _site_ license and all source code.
If VOCOM+ had Event support, i had bought it immediatly.
I think some other customers, too.
>> >You want me to do really difficult low-level COM work for you in VO and
>in
>> >return you get to have fun and play and learning with the exciting new
>.NET
>> >language CULE? This hardly seems fair <g>.
>>
>> But it is!
>>
>> I meant a really difficult indeep multiple context evaluation, which
>> means for me "stop to live for those 2-3 days".
>
>I think if you take those 2-3 days and apply them to your COM Events sinking
>issue you will solve your problem. Then maybe you will share it with the VO
>community on your own.
I'm not able to produce the results you could produce in timeframe 3
days for "COM Events sinking with VOCOM".
You're not able to produce the results i could produce in timeframe 3
days for "indeep multiple context evaluation of CULE.NET".
A simple trade.
(please do not forget to sent me an offer your payed services!)
> As I said I will try and find you all relevant VOCOM
>code I have on the subject, but you must give me a few days as I am out of
>the office for a while.
Thanks again for this kindly offer.
>The CULE.NET beta test team would value your participation (we don't even
>ask you to stop living <g>), but it will have to come from your own free
>will...
I understand your philosophy.
Whatever the circumstances/conditions are:
It would come from my own free will.
>HTHs, (and with apologies for the long post)
Apology granted!
Please be so kindly to answer/comment those 2 things you've maybe
overseen whilst writing the long post:
1st thing i've wrote:
"
What about the "runtime only implementation of events" you've
mentioned?
If there is any source available?
"
-
2nd thing:
"
>> VO product champion, who was this?
>>
>
>Names aren't important.
But you mention one of the 2 persons by name (Charles Wong/Wang):
"
Charles decreed that there would be a 2.5 release and the VO product
champion (who was also the head developer/lead architect)
"
I think it is friendly against the readers to write the name, thus
they know who is (or was) the head developer/lead architect of VO.
Especially as this is an VO-Group.
(i try a quick search, but i fail)
"
>Rod
Rod da Silva
> Of course not. "Automation-Server-Events" is the topic.
>
> I meant only what we discussed: 2-3 days for the codegenerator.
Do you think you are the only person to ask me for a VOCOM "extension"? You
have to get in line <g>. Automation-Server-Events may be your agenda but
there are others out there with their own COM needs as well. My point was
there are lots of things that "could" be added to VOCOM if I was so
inclined.
>
> Your answer starts with: "No i won't be investing anymore time..."
> [refers to future]
>
> But my question started with: "Why until now..."
> [refers to past]]
>
Well my philosophy as laid out in my last post has been in place for a few
years now so I have had my "future" attitude for quite some time now <g>.
> >In fact that's how type library
> >support got into VOCOM+ - a customer needed it and paid me to write it
for
> >him at a negotiated lower price than I would normally charge in order for
me
> >to keep the rights to the software.
>
> [Remark: I'm not sure, if this is the "fairplay" solution, as this
> developement raises incoming from VOCOM+ sales (as some other
> customers will buy it for exact this reason).]
>
Not following you here. I made a simple trade. My time at half price for
the rights to the software that was developed for the customer. It was a
win-win-win as far as I was concerned. The customer got what they wanted, I
got a valueable addition to VOCOM and VOCOM+ users got the benefit of that
work in official support for TypeLibs. What's "unfair"? Should I not
profit from my investment (50% of my time over 10 days == 5 days worth of
work)? Moreover, aren't you asking me to do the same thing in away? Strike
a "deal" to do some work from you and then add it in to the base product for
other's benefit? I am confused by your statement.
> I've written [maybe not in an clear context]:
>
> "Please use email to send me your offer."
>
> This is still valid: please send me an offer via email.
> ....
> I'm not able to produce the results you could produce in timeframe 3
> days for "COM Events sinking with VOCOM".
>
> You're not able to produce the results i could produce in timeframe 3
> days for "indeep multiple context evaluation of CULE.NET".
>
> A simple trade.
>
> (please do not forget to sent me an offer your payed services!)
You are sending me mixed signals. Are you proposing a time trade or do you
want me to quote on the work for hire? I have clearly stated I am not
interested in a time trade. I would consider quoting on the work however -
all proceeds going to the CULE Project Development fund of course <g>.
>
> A library-product should encapsulate the domain-knowledge (e.g. API
> etc.) fully, thus the developer does not need to go into the details.
>
VOCOM encapsulates the COM specification accurately and robustly. That is
the domain-knowledge I claim for the product.
> On the other hand, the product should provide if possible all details
> of the implementation (source-code, domain-knowledge) if an developer
> wants to modify / correct / fully understand the code.
>
VOCOM source code is provided with the purchase of VOCOM+.
> Finally it should give some extension domain-knowledge, to give the
> devolopers a starting-point and a motivation to extend the product
> (here: adding Events to VOCOM).
>
VOCOM's libraries are as open as you want to get. You can use the product
to build anything in COM universe. Where we differ is that you seem to be
suggesting I owe people a tutorial on COM (or more specifically COM events).
Sorry, but this it out of the scope of the packaged product. "Inside OLE
2.0" was the COM/OLE bible when I was writing VOCOM. It was 1500 pages
thick or something ridculous. There is good reason for this. COM/OLE is a
massive topic. My goal was to write a product that allowed for the creation
of any of the samples in that book in VO rather than C++. I stopped short
of actually porting the samples <g>.
> The starting-point is the barrier.
>
Yup! I am sorry if you have been mislead but you will not find the starting
point for your COM eduction in VOCOM. You need to go and read up about COM
in general, and specific sub-technologies of COM (such events, compound
structured storage, linking and embedding, ActiveX controls, COM+, etc.,
etc., etc.,) before sitting down to work with VOCOM.. The only thing I have
ever claimed about VOCOM is it will make your COM programming in VO
infinately easier than it otherwise would be. The assumed prerequisite is
knowledge of COM programming concepts (whats an interface, what's a COM
object, what's a class factory, what's an event source, what's an event
sink, etc..).
In all the years I have been supporting VOCOM I can only recall what I would
consider to be one really unhappy customer (at least one that complained
loudly to me). The company bought VOCOM because they wanted to do MTS 1.0
programming in an ASP environment. Well they bought VOCOM and installed it
and then said okay now what? So I put together a small ASP sample for them
(which is one my web site and many here have downloaded it). It
demonstrated how to hook into the various objects (response, etc.,) that ASP
supports when doing ASP programming with COM objects. So they got this
working but next they wanted to know why they weren't able to get their MTS
transaction stuff working. I tried to explain that if they wanted to tap
into this stuff they had to implement IObjectContext and related objects
that MTS provides for this purpose. They got a little angry as they felt
that VOCOM should support that out of the box. I tried to explain that
there are 1000s of published COM interfaces from Microsoft and it was
impossible to support them all. Rather VOCOM takes a minimalistic approach,
implementing only the bear minimum set of interfaces like IUnknown,
IDispatch and IClassFactory. The idea is to provide the core technology
that allows the user the ability to support any COM interface yourself.
My point was and is one of scope. VOCOM's scope is to provide COM
programming capabilities in VO, period. If you have interest in a
particular COM interface, _you_ must implement it yourself. VOCOM gives you
everything you need to do this. If people expect more from VOCOM
(notwithstanding the highlevel ActiveX Server creation wizard which is not
relevant to this discussion) then they simply do not understand COM to a
level necessary to really use VOCOM in the first place. Like I said before
VOCOM is largely misunderstood.
> Even if you are right in your saying, that most customers don't look
> at the examples, you should provide them for those few which go the
> right way.
If you have the prerequisite COM knowledge (i.e.; you know what a COM
interface is and how to use it) then the IAnimal sample is all you need to
learn how to write COM interfaces using VOCOM.
> Please be so kindly to answer/comment those 2 things you've maybe
> overseen whilst writing the long post:
>
> 1st thing i've wrote:
>
> "
> What about the "runtime only implementation of events" you've
> mentioned?
>
> If there is any source available?
> "
>
I will try and find you _all_ VO source I have on the subject of COM Events.
> -
> I think it is friendly against the readers to write the name, thus
> they know who is (or was) the head developer/lead architect of VO.
>
> Especially as this is an VO-Group.
>
> (i try a quick search, but i fail)
> "
>
I forget his name. I am not very good with names. In fact my memory for
most things is going at an alarming rate. In a few years I will be able to
hide my own Easter Eggs <g>.
The only reason I remember Charles (and only his first name - can't remember
if its Wong or Wang) is because he is the only billionare I have ever met.
You tend to remember things like that. Beyond that, however, there was not
much memorable about the man <g>.
HTHs,
Rod
Ginny Caughey
The architect for VO 1 was Anders Vinberg. I don't think VO 2 and beyond ever
had a single architect and instead just got new features that CA developers
thought were interesting at the time implemented however the individual
developers wanted. I think this is why some new libraries were written in VO,
but most were written in C++ as most of the CA developers never really used VO
themselves AFIAK.
--
Ginny
Rod da Silva
It pleases me that you found/find VOCOM/VOCOM+ so useful. And thank you
for _your_ support all these years. You have been great at helping people
with their VOCOM questions.
Rod
Greg Garza
FWIW, his name is Charles Wang (pronounced Wong).
Greg
Phil McGuinness
just got new features that CA developers thought were interesting at the
Aint that the truth.......!
Phil McGuinness - Sherlock Software
----
"Ginny Caughey" <ginny....@wasteworks.com> wrote in message
news:bccna5$hklkr$1...@ID-144704.news.dfncis.de...
Phil McGuinness
There are many VOCOM users... I may not use it by I bought it..
[ I thought you needed the money to buy some new Ice Hockey gear <g> ]
But at the time I could not find a use.. but then I had no real idea what it
did !
I have used it twice.. ince with Willies Email thing to have a look and Mark
Lincoln got the hand coded reports in Report Pro III running for me as well.
Is it possible / feasable that if enough hold their hands up and a set of
features is proposed and price agreed to.. that you would deliver an upgrade
you would do a VO2.7 version. Extra documentation and examples nevers goes
astray either. After all WIN32API programming is going to be around the
next 5-10 years.
I guess if I had of used VOCOM I could have exposed a VO application I wrote
to interface with PHP but we ended up writing all in PHP in the end.
OK.. guys what specific features are we looking for..?
Phil McGuinness - Sherlock Software
---
"Rod da Silva" <RodDa...@SoftwareP.com> wrote in message
news:bcco45$g1$1...@ngspool-d02.news.aol.com...
Gary Stark
You are being eternally patient here. <g>
> > -
> > I think it is friendly against the readers to write the name, thus
> > they know who is (or was) the head developer/lead architect of VO.
> >
> > Especially as this is an VO-Group.
> >
> > (i try a quick search, but i fail)
> > "
> >
>
> I forget his name. I am not very good with names. In fact my memory for
> most things is going at an alarming rate. In a few years I will be able to
> hide my own Easter Eggs <g>.
I resemble that remark. Seriously. I'm noticing it more and more when I go out
jamming these days, and I can no longer recall how a song goes. Once I hear a
bar or two (or somebody fronts up to the bar and buys me a round or two) I'm
fine ... but this concerns me because it's something that, for me, is
back-of-the-hand stuff.
> The only reason I remember Charles (and only his first name - can't remember
> if its Wong or Wang) is because he is the only billionare I have ever met.
> You tend to remember things like that. Beyond that, however, there was not
> much memorable about the man <g>.
I believe that there were two people within CA who held the title of "Product
Champion" for VO (and Clipper, IIRC) at various times. David Morgan was one, and
Luiz somethingorother the other. There may have been a third one later on too,
but I can't say this with certainty.
Product owners (who were not the same as champions) included, at various times,
Yogesh, One Elle, The Iceman, and Sabo.
HTH.
ilias
<RodDa...@SoftwareP.com> wrote:
>Ilias (promising to keep this one short and to the point)
>
>> Of course not. "Automation-Server-Events" is the topic.
>> I meant only what we discussed: 2-3 days for the codegenerator.
>
>Do you think you are the only person to ask me for a VOCOM "extension"? You
>have to get in line <g>. Automation-Server-Events may be your agenda but
>there are others out there with their own COM needs as well. My point was
>there are lots of things that "could" be added to VOCOM if I was so
>inclined.
I understand this.
I'm not focusing on "Automation-Server-Events" as they are in my
agenda.
At least not only.
>> Your answer starts with: "No i won't be investing anymore time..."
>> [refers to future]
>> But my question started with: "Why until now..."
>> [refers to past]]
>
>Well my philosophy as laid out in my last post has been in place for a few
>years now so I have had my "future" attitude for quite some time now <g>.
Now it's clear.
It is your full right to have this philosophy and to do your business
this way.
I respect this completely!
Any customer can decide.
Based on the information you give him prior to purchasing your
product.
>> >In fact that's how type library
>> >support got into VOCOM+ - a customer needed it and paid me to write it
>> >for him at a negotiated lower price than I would normally charge in
>> >order for me to keep the rights to the software.
>>
>> [Remark: I'm not sure, if this is the "fairplay" solution, as this
>> developement raises incoming from VOCOM+ sales (as some other
>> customers will buy it for exact this reason).]
>
>Not following you here. I made a simple trade. My time at half price for
>the rights to the software that was developed for the customer. It was a
>win-win-win as far as I was concerned. The customer got what they wanted, I
>got a valueable addition to VOCOM and VOCOM+ users got the benefit of that
>work in official support for TypeLibs. What's "unfair"? Should I not
>profit from my investment (50% of my time over 10 days == 5 days worth of
>work)?
I respect your business philosophy.
As long as it was cleary announced, that VOCOM+ is a low-level
COM-library and has no support for tlb, the above deal is
"full-fairplay".
[Sometimes a term 'implies' expectations of functionality. COM
'implies' typelib, thus many customer could expect this functionality.
pre-sales-documentation must clarify this, so customers don't run into
surprises].
>Moreover, aren't you asking me to do the same thing in away? Strike
>a "deal" to do some work from you and then add it in to the base product for
>other's benefit?
The fact that i ask for a deal does not imply anything about my
"fairness-rating" for this deal.
>I am confused by your statement.
i hope i have clarified.
>> I've written [maybe not in an clear context]:
>> "Please use email to send me your offer."
>> This is still valid: please send me an offer via email.
>> ....
>> I'm not able to produce the results you could produce in timeframe 3
>> days for "COM Events sinking with VOCOM".
>> You're not able to produce the results i could produce in timeframe 3
>> days for "indeep multiple context evaluation of CULE.NET".
>>
>> A simple trade.
>> (please do not forget to sent me an offer your payed services!)
>
>You are sending me mixed signals. Are you proposing a time trade or do you
>want me to quote on the work for hire? I have clearly stated I am not
>interested in a time trade.
No, you haven't.
You have implied this.
> I would consider quoting on the work however -
>all proceeds going to the CULE Project Development fund of course <g>.
Yes, please sent me a quote for this work:
- create an IDE extension "codegenerator for Automation-Server with
Events".
- rebate when you keep the rights on source.
>> A library-product should encapsulate the domain-knowledge (e.g. API
>> etc.) fully, thus the developer does not need to go into the details.
>
>VOCOM encapsulates the COM specification accurately and robustly. That is
>the domain-knowledge I claim for the product.
ok.
>> On the other hand, the product should provide if possible all details
>> of the implementation (source-code, domain-knowledge) if an developer
>> wants to modify / correct / fully understand the code.
>
>VOCOM source code is provided with the purchase of VOCOM+.
Ok.
This sounds fair.
[clarification: the VOCOM_+_ sourcecode is provided, too]
>> Finally it should give some extension domain-knowledge, to give the
>> devolopers a starting-point and a motivation to extend the product
>> (here: adding Events to VOCOM).
>
>VOCOM's libraries are as open as you want to get.
[...]
>My goal was to write a product that allowed for the creation
>of any of the samples in that book in VO rather than C++. I stopped short
>of actually porting the samples <g>.
Now i understand.
>> The starting-point is the barrier.
[...]
>The only thing I have
>ever claimed about VOCOM is it will make your COM programming in VO
>infinately easier than it otherwise would be.
[...]
That was the point i miss.
Now it's clear.
>In all the years I have been supporting VOCOM I can only recall what I would
[,,,]
>IDispatch and IClassFactory. The idea is to provide the core technology
>that allows the user the ability to support any COM interface yourself.
ok
>My point was and is one of scope. VOCOM's scope is to provide COM
>programming capabilities in VO, period.
[...]
> Like I said before
>VOCOM is largely misunderstood.
As long as you clarify this in pre-sales, it is not your fault.
>> Even if you are right in your saying, that most customers don't look
>> at the examples, you should provide them for those few which go the
>> right way.
>
>If you have the prerequisite COM knowledge (i.e.; you know what a COM
>interface is and how to use it) then the IAnimal sample is all you need to
>learn how to write COM interfaces using VOCOM.
ok.
>> Please be so kindly to answer/comment those 2 things you've maybe
>> overseen whilst writing the long post:
>>
>> 1st thing i've wrote:
>> "
>> What about the "runtime only implementation of events" you've
>> mentioned?
>>
>> If there is any source available?
>> "
>
>I will try and find you _all_ VO source I have on the subject of COM Events.
Very nice!
>> I think it is friendly against the readers to write the name, thus
>> they know who is (or was) the head developer/lead architect of VO.
>> Especially as this is an VO-Group.
>> (i try a quick search, but i fail)
>> "
>
>I forget his name. I am not very good with names. In fact my memory for
>most things is going at an alarming rate. In a few years I will be able to
>hide my own Easter Eggs <g>.
Forgetting is an ability.
Inhibition of the irrelevant.
>The only reason I remember Charles (and only his first name - can't remember
>if its Wong or Wang) is because he is the only billionare I have ever met.
>You tend to remember things like that. Beyond that, however, there was not
>much memorable about the man <g>.
I assume he looks like other humans.
Lets see:
http://goldsea.com/Air/Issues/WangC/wangc.html
>HTHs,
>
>Rod
>
And don't forget:
"
Yes, please sent me a quote for this work:
- create an IDE extension "codegenerator for Automation-Server with
Events".
- rebate in %, if you keep the rights on source.
"
-
[dummy content to force mailgate.org server to accept this post, as it
weights quoted/new text and rejects post]
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Ed Richard
> So would you do DBFCDX.NET if you were Brian? <g> Would you do a VO.NET?
I would have done DBFCDX.NET two years ago if I had the money to invest and
was in the position Brian is. I do understand why Brian hasn't.
I think there's a big market for a low-cost smal scale datastorage solution
(file based, cheap and easy to deploy) for .NET that's not SQL based. But
it's just a feeling not based on any research or facts. It seems to be a
reason why people still develop in Clipper and VO.
VO.NET, I'm not so sure about anymore although there will be a need for a
migration path. Problem is the market is not big enough if you ask me. In
Brians' shoes, .net is probably the only path that makes much sense for VO's
future.
> Let me throw another thought out there. Lets jump ahead 3 years and the
> .NET market begins to shake out.
I think languages like Smalltalk or Eiffel will be around and there will be
more emphasis on metadata and metadatadriven application development (I
didn't say programming <g>).
Ed
Marc
> I think there's a big market for a low-cost smal scale datastorage solution
> (file based, cheap and easy to deploy) for .NET that's not SQL based.
Why is it important here that such a solution _NOT_ be SQL based?
How about something that is low-cost, highly robust, easy to deploy,
and offers BOTH traditional DBF style access _and_ full SQL?
Finally, what good is a .NET datastorage engine if it's being used from a
non-.NET program?
-Marc-
Ginny Caughey
I thought DBFCDX.NET was a great idea myself two years ago and even told Brian
so. Now I'm not sure it would make much money on the desktop since people are
just using OleDb these days to talk to DBFCDX data as far as I can tell. Where
it might make a nice impact would be on smart devices. SQL Server CE is more
than some people want to use on a small device, and DBF files are really a
perfect fit there. But there is no data driver for DBF on CE. Codebase is one
solution, but it is much more labor intensive, and not usable by .Net at all
unless you write your own wrapper code in C++. (They missed this market too!) I
still think there could be a profitable niche there.
--
Ginny
"Ed Richard" <e.d.Richard_No@Spam_Chello.nl> wrote in message
news:8LgHa.12019$KF1.273586@amstwist00...
Ginny Caughey
The non-.Net program may not be the only program that will ever want to access
the data. If a data storage engine can be used by both, that makes it much more
useful.
--
Ginny
"Marc" <Ma...@Fpss.Net> wrote in message news:3EEDC8E2...@Fpss.Net...
Rod da Silva
<<As long as it was cleary announced, that VOCOM+ is a low-level
COM-library and has no support for tlb, the above deal is
"full-fairplay".
[Sometimes a term 'implies' expectations of functionality. COM
'implies' typelib, thus many customer could expect this functionality.
pre-sales-documentation must clarify this, so customers don't run into
surprises].
>>
I have always been very up front with people about VOCOM's capabilities and
its limitations.
>
> Forgetting is an ability.
Well then I am very good at it! <g>
> Yes, please sent me a quote for this work:
> - create an IDE extension "codegenerator for Automation-Server with
> Events".
> - rebate in %, if you keep the rights on source.
> "
I will put together a quote for you to do this work and e-mail it to you in
the coming days.
Rod
Rod da Silva
<<Is it possible / feasable that if enough hold their hands up and a set of
features is proposed and price agreed to.. that you would deliver an upgrade
you would do a VO2.7 version.>.
Don't you know Phil that "anything" is possible <g>?
Rod
Ginny Caughey
And as far as my (faulty) memory goes, only two of the product champions
actually championed the product. <g>
--
Ginny
"Gary Stark" <3061...@RedbacksWeb.com> wrote in message
news:3EEA8936...@RedbacksWeb.com...
ilias
<RodDa...@SoftwareP.com> wrote:
>Ilias
[...]
>> Forgetting is an ability.
>
>Well then I am very good at it! <g>
xexe!
[...]
>I will put together a quote for you to do this work and e-mail it to you in
>the coming days.
Don't... forget it !
Thank you for answering all of my questions with patience.
Wish you always the best business.
>
>Rod
>
Marc
> But there is no data driver for DBF on CE.
Maybe the ADS local server...?
-Marc-
Ginny Caughey
I don't know of any .Net drivers for CE other than for SQL Server and SQL CE at
present. I believe there is one from Oracle in the works but I don't know of any
others. There is no generic OleDb .Net driver for the Compact Framework.
--
Ginny
"Marc" <Ma...@Fpss.Net> wrote in message news:3EEDF11F...@Fpss.Net...
Rod da Silva
See the new thread elsewhere in this newsgroup entitled "VOCOM Events Sample
Available for Download" for a simple sample that shows how to sink to
COM/OLE events from VOCOM code. It should give you everything you need to
do your own COM event sinking solution.
HTHs,
Rod
Ed Richard
> Why is it important here that such a solution _NOT_ be SQL based?
>
> How about something that is low-cost, highly robust, easy to deploy,
> and offers BOTH traditional DBF style access _and_ full SQL?
Don't get me wrong, I would always be in favor of an SQL or ADS solution,
but it seems to be important to a lot of developers to have a solution they
can distribute with their apps for free and have great control over. The DBF
file format seems be something a lot of developers are familiar with, and
they feel comfortable with the level of control. Being able to open the
files, repair if needed etc.
>
> Finally, what good is a .NET datastorage engine if it's being used from a
> non-.NET program?
No good at all, I was thinking of .net development like CULE or even an easy
option for vb or c#. It seems to me that the move to the .NET environment is
hard enough for many people, if they have to move to a SQL-environment as
well at the same time it's just a big leap for a lot of people.
I've seen a lot of developers move to VO, but writing scatter/gather code at
first in stead of using dbServer objects, same thing I guess.. Not a good
thing, but it seems to happen a lot.
Ed
Graham McKechnie
I agree that Sql Server CE is a bit over the top for smart devices. Its fine
if your desktop data is Sql, but the biggest problem I have with it, now I
got over the speed issue is size. My Palm data which is 3.5 meg ( which I
thought was big at the time<g>) became 22meg on the Pocket PC. I was
surprised I could still pick it up.
It works, but that is a lot of memory chewed up for one app.
However I doubt a dbf .Net solution would be much better (for smart devices)
as it too would chew up about the same amount of memory.
A better solution on a Pocket PC, would be to mimic a Palm database solution
, where not a byte is wasted.
Regards
Graham
"Ginny Caughey" <ginny....@wasteworks.com> wrote in message
news:bckij0$k6ff8$1...@ID-144704.news.dfncis.de...
Ginny Caughey
I suspect the reason really tight data structures haven't surfaced as products
for CE is that CE devices increasingly have large data capacity. As you said,
even though your data ballooned, it still fit. You're right that any data
structure with fixed-length fields and records, such as DBF files, will always
take up more room than more compact ones.
--
Ginny
"Graham McKechnie" <g...@bigpond.net.au> wrote in message
news:CDsHa.7500$GU5.1...@news-server.bigpond.net.au...
Gary Stark
Graham McKechnie wrote:
> However I doubt a dbf .Net solution would be much better (for smart devices)
> as it too would chew up about the same amount of memory.
>
> A better solution on a Pocket PC, would be to mimic a Palm database solution
> , where not a byte is wasted.
>
One interesting aspect of the AppForge toolset is that you use the .pdb format
on a CE device. I wonder what would be involved in just taking their CE API and
using just the PDB library from it?
--
Ginny Caughey
Interesting idea, but if space isn't a problem...
--
Ginny
"Gary Stark" <3061...@RedbacksWeb.com> wrote in message
news:3EEE5999...@RedbacksWeb.com...
Marc
ADS has a free rdd that supports both DBF and SQL.
You can even mix both in the same app.
It's as easy to use as the current DbfCdx rdd and completely compatible.
I believe it does or will soon support .Net
-Marc-
Phil McGuinness
restored" ?
OK boys and girls... what features do we want and what are the numbers of
takers..
Phil McGuinness - Sherlock Software
---
"Rod da Silva" <RodDa...@SoftwareP.com> wrote in message
news:bckisj$ifj$1...@ngspool-d02.news.aol.com...
Graham McKechnie
When I get this stuff, I'm going to have a go at doing pdb format on PPC.
Graham
"Gary Stark" <3061...@RedbacksWeb.com> wrote in message
news:3EEE5999...@RedbacksWeb.com...
Jamie Macleod
I've developed a reader/writer class in C#. I hoping to use it on the
PocketPC as my "database engine" so I can read the same database on both my
Palm and Pocket PC versions of the application. The class is not dynamic
though. In other words, I read into the dataset, do changes and write out
the changes to a new (overwrite) file. I would really like to have a DBF
style PDB interface so I could gotop, seek, skip, etc. With the way the pdb
file is set up though you need to be able to insert bytes into the middle of
a file, and shift the rest of the bytes in the file to make it larger.
There must be a way to do this, but I haven't figured it out.
Jamie
"Graham McKechnie" <g...@bigpond.net.au> wrote in message
news:jtuHa.7660$GU5.1...@news-server.bigpond.net.au...
Jamie Macleod
client. You end up having to hand code most your database code (ie the IDE
tools don't work with ADS OleDB), but I prefer this anyways. The .Net
client for ADS won't be available until after version 7.0 of the database
server is realeased (September) I believe. The .NEt client will be version
7.01 or something like that.
Jamie
"Marc" <Ma...@Fpss.Net> wrote in message news:3EEE72E7...@Fpss.Net...
Gary Stark
Jamie Macleod wrote:
> Gary,
>
> I've developed a reader/writer class in C#. I hoping to use it on the
> PocketPC as my "database engine" so I can read the same database on both my
> Palm and Pocket PC versions of the application. The class is not dynamic
> though. In other words, I read into the dataset, do changes and write out
> the changes to a new (overwrite) file. I would really like to have a DBF
> style PDB interface so I could gotop, seek, skip, etc. With the way the pdb
> file is set up though you need to be able to insert bytes into the middle of
> a file, and shift the rest of the bytes in the file to make it larger.
> There must be a way to do this, but I haven't figured it out.
The people at AppForge seem to have that part worked out then. Whilst the
interface to their PDBLibrary is not xBase, it's also not too far from it
either. And you can use the exact same codebase to build your applications for
either a PalmOS or CE target. That aspect is a very nice feature.
But I agree with you that either a PDB or xBase engine for C# would certainly be
nice to have.
Jamie Macleod
ilias
This makes me really happy.
In a wide scope.
-
VOCOM Events Sample Available for Download
http://groups.google.com/groups?selm=bcl41q$cf6$1...@ngspool-d02.news.aol.com
direct download link:
http://www.softwareperspectives.com/VOCOM/VOCOMEvents.zip
>
>HTHs,
>
>Rod
>
ilias
[...]
>Did anyone use this library for contacting(!) automation servers with
>events?
Direct download link:
http://www.softwareperspectives.com/VOCOM/VOCOMEvents.zip
Graham McKechnie
>>
With the way the pdb file is set up though you need to be able to insert
bytes into the middle of
a file, and shift the rest of the bytes in the file to make it larger.
There must be a way to do this, but I haven't figured it out.
>>
Yes that has been holding me back too.
However we know all the offsets before the insert and we can calculate the
new ones for the records that are pushed along based on the length of the
new record. Therefore we just need to rewrite the new offsets, plus push it
all down some, plus the new data.
It sounds slow, but I can't think of another way. But remember we are only
writing to memory anyway.
Jamie an off topic question - how do you handle writing dates to Sql Ce
Server. Ce Server seems to want a date as 20030617. But all my stuff is
17/06/2003, so when you string.format an insert you get screwed. Do you use
CultureInfo?
Graham
"Jamie Macleod" <bubam...@yahoo.com> wrote in message
news:n9xHa.3645$b77.1...@news2.telusplanet.net...
> Sorry I meant Graham.
>
>
Jamie Macleod
Sorry I'm no help. I am using CSV text files and pdb files for my data. My
database is quite simple on the PDA and I find it quick to use these
formats. I tried XML but found it was slow and make the data files to big.
Jamie
"Graham McKechnie" <g...@bigpond.net.au> wrote in message
news:mtCHa.335$y77....@news-server.bigpond.net.au...
Jamie Macleod
manually like Graham is suggesting.
"Gary Stark" <3061...@RedbacksWeb.com> wrote in message
news:3EEE8E88...@RedbacksWeb.com...
Ginny Caughey
Have you considered using delimited ascii files? They are quick to parse, very
fast to use if you don't use Datasets, and are about 1/10 the size of XML. The
main downside is inserting data, so you have to figure out some way to
invalidate earlier records and replace them with newer ones later in the file -
not a big deal though. The other downside for huge databases like Graham's is
that you have 2 copies when you're finished parsing, one in memory and the other
on "disk".
--
Ginny
"Jamie Macleod" <pocket...@yahoo.ca> wrote in message
news:%KFHa.12872$T85.1...@news1.telusplanet.net...
Jamie Macleod
aren't that big. Is this what you are doing?
"Ginny Caughey" <ginny....@wasteworks.com> wrote in message
news:bcn9ri$l1dq3$1...@ID-144704.news.dfncis.de...
Adriano Rui Gominho
On Mon, 16 Jun 2003 23:44:34 GMT, "Graham McKechnie"
<g...@bigpond.net.au> wrote:
>Hi Ginny,
>
>.... My Palm data which is 3.5 meg ( which I
>thought was big at the time<g>) became 22meg on the Pocket PC. I was
>surprised I could still pick it up.
>
"Where do you want to go today? We'll take you there on a Humvee!"
Adriano
Gary Stark
Jamie Macleod wrote:
> I'd be interested to know how they did it. I'm wondering if they did it all
> manually like Graham is suggesting.
I dunno, but it's certainly quite usable technology, especially with the
functionality of being cross-platform.
I would suspect that with the internal knowledge of PDB files that guys like
you, Steve and Grum have, it shouldn't be too dificult to write a PDB control in
MS C++ for the CE and DotNet platforms ...
Gary Stark
Ginny Caughey wrote:
> Jamie,
>
> Have you considered using delimited ascii files? They are quick to parse, very
Depending upon how much data you have, they can be very effecient. I've been using
them since day 1. I find them especially efficient for small amounts of transient
data, and transfers of the data between the host and remote devices take but
milliseconds to perform.
--
Karl-Heinz Rauscher
i´m watching the Vistasoftware activities for a while now - and i still
don´t know if they will ever finish anything <g>. Their DBF .net
migration path seems to be:
1. using the SDE ( ex Successware ) unmanaged C-Dll
2. using the completely rewritten Apollo 7 engine.
The Apollo 7 engine uses SQL syntax to access DBFs, while the SDE-DLL is
more or less the same route as using VO´s DBF engine via pinvoke. I
must admit that a full managed .NET dll would be better than to access VOs
API via pinvoke, but i doubt that Brian will ever transfer the C ( and
maybe ASM ? ) code to pure .NET.
Anyway, if you´re interested in a poor man´s .net DBF solution you might
take a look at my homepage ( cudbf.zip) . It´s not the latest version - in
the meantime i´ve done some more enhancements - but it might give you some
hints about the pro and contra of using DBFs in a .NET environment.
--
regards
Karl-Heinz
CULE - the easier C#, the smarter VO
ilias
Note:
This sample deals not with out-of-process AutomationServers (EXE).
If you are not familar with COM / VO / VOCOM, you'll may not be able
to produce a running implementation.
ilias
ilias
The following sample deals with out-of-process AutomationServers
(EXE).
A small TestAutomationServer is included.
http://groups.google.com/groups?selm=bdsmht$epr$1...@ngspool-d02.news.aol.com
direct link:
http://www.softwareperspectives.com/VOCOM/VOCOMSinker.Zip