Converting a userspecific VCL-component to an ActiveX-control
Ulrich Korndoerfer
for my next application I need to integrate HTML rendering capabilities.
HTML along with CSS and callbacks from user events shall be used to
render data from a database and to build substantial parts of the GUI.
I sought for long for some tool to buy. For various reasons I do not
want to use IE or the Mozilla control. Up to now I found two tools which
seem to fulfill my needs:
- HTMLayout, a standard DLL which is said to be available in
the future as ActiveX control too.
- ThtmlViewer and its descendants, a VCL-component written in Delphi,
available with source code.
From those two, I would prefer ThtmlViewer. However I can not use a
VCL-component in direct, as my programming environment is not CBuilder
or Delphi. I can use any standard windows dll or ActiveX control.
For me being able to use ThtmlViewer, ThtmlViewer as a visual component
must be converted to a standalone ActiveX control (should not have VCL
runtime dependencies, such should be statically linked). Unfortunately
the manufacturer of this component does not offer an ActiveX version.
But he agrees if I do the conversion on my own.
After some research now I know, that this basically is possible and
would be assisted by some Delphi wizards. Of course some fine polishing
would have to be done after the automatic transformation. Delphi can
create a COM-wrapper which already has implemented all supplementary
COM-interfaces. For the VCL-component the COM-interface would be created
too, but not fully implemented. This is where some own work would have
been to be done. But I do not have any clue how much effort this will
cost. And I do not have Delphi nor CBuilder.
So before I go into this any deeper some starting questions:
- Am I right that converting a rather complex VCL GUI component,
which uses quite a lot of VCL specific types or types derived
from those in its interface (like a descendant of TPanel,
TStringLists, TMemoryStreams, a descendant of a TBitmap and
others more) to a standalone ActiveX control can be done?
- Can it be done in a reasonable time with reasonable effort
(lets say one to two weeks)? Or will it be a nightmare,
first when converting and later when using?
- Perhaps someone out there already has done this and would share
his results with me? Although for now I don't know how to handle
this correctly without breaking the manufacturers license: it
does not allow to build a standalone control from his component
and to sell this as standalone control. However he told me, if
I would do the conversion myself and solely use it in my
application, I am allowed to deploy it with my application.
The converted control then should have some licensing mechanism
which hinders the end user from using the control in its own
applications.
All replies are welcome.
--
Ulrich Korndoerfer
VBDis
<ulrich_wa...@prosource.de> schreibt:
>- Am I right that converting a rather complex VCL GUI component,
> which uses quite a lot of VCL specific types or types derived
> from those in its interface (like a descendant of TPanel,
> TStringLists, TMemoryStreams, a descendant of a TBitmap and
> others more) to a standalone ActiveX control can be done?
IMO the efforts depend only on the methods and properties that are exposed in
the ActiveX interface. The ActiveX component (EXE or DLL) will contain all
required VCL and RTL parts, accessible from outside only by the methods defined
and implemented in the ActiveX class.
DoDi
Ulrich Korndoerfer
(aren't you this fabulous, possible german, VB disassembler crack? ;-))
VBDis wrote:
Thats what one of my main concerns is. The interface uses many native
VCL or derived types. I would have to write wrappers for each VCL type
which is not OLE automation compatible. And this for one who is VCL
illiterate :-(. Thank You for affirmating this.
--
Ulrich Korndoerfer
Bjørge Sæther
> Hi,
>
> for my next application I need to integrate HTML rendering capabilities.
> HTML along with CSS and callbacks from user events shall be used to
> render data from a database and to build substantial parts of the GUI.
I didn't understand what you want this for:
- Render HTML into a visual representation in a Windows application, or
- Use Windows controls for displaying in a browser ?
Ulrich Korndoerfer
Bjørge Sæther wrote:
> I didn't understand what you want this for:
>
> - Render HTML into a visual representation in a Windows application, or
> - Use Windows controls for displaying in a browser ?
The first one of these two.
I will write a standard windows desktop application.
One part of this application shall be a control being able to render
HTML. This control will be placed on a window. User chooses to display
some data, I fetch this data from a database, embedd this data into HTML
code and give this HTML to the control for rendering.
The second part shall be building parts of the applications user
interface with HTML. Think of it like doing traditional dynamic HTML.
The differences between traditional dynamic HTML and my approach are:
- trad. DHTML for implementation of behaviour uses client side scripting
with scripts embedded in the HTML. The script code is extracted by the
browser and given to a script interpreter. The interpreter then executes
this code. Also the interpreter has access to the DOM of the HTML, such
allowing modification of the HTML code through the script. Code
execution is triggered by events (user events, timer events, or doucment
events like document loading, showing and so on).
- In my approach behaviour is implemented using events (or callbacks,
notifications or whatever you like to name it) too. The renderers part
is it to give the application which embeds it these events. An event can
be as simple as saying "a link has been clicked". Or "mouse has hovered
an image". But the events then trigger execution of code which is
application code, right compiled into the application. The advantages of
this are: the renderer may be much more simpler as a full fledged
brwosing component like IE or Mozilla control. It is much faster than
interpreted script code as application code is compiled to native
assembler code. And I gain much more control and flexibility than with
trad. DHTML.
Also my approach allows (if the renderer supports it, which ThtmlViewer
does) to embed classic windows controls (like a listview, treeview and
the like) in the visual representation of the HTML. The renderer takes
care of the positioning and sizing of the control and takes its
existence into account when rendereing the rest (such eg. text will flow
nicely around an embedded control, or automatic reaction on windows
resizing can be achieved with no extra effort on the applications side).
--
Ulrich Korndoerfer
Ulrich Korndoerfer
>> I didn't understand what you want this for:
>>
>> - Render HTML into a visual representation in a Windows application, or
>> - Use Windows controls for displaying in a browser ?
>
>
> The first one of these two.
Better is: I want both :-)
--
Ulrich Korndoerfer
VBDis
<ulrich_wa...@prosource.de> schreibt:
>(aren't you this fabulous, possible german, VB disassembler crack? ;-))
Correct! :-)
>Thats what one of my main concerns is. The interface uses many native
>VCL or derived types.
Which interface? The ActiveX class can be totally different from the Delphi
class. It's up to you to define the ActiveX class, so that the user can access
your component.
> I would have to write wrappers for each VCL type
>which is not OLE automation compatible. And this for one who is VCL
>illiterate :-(. Thank You for affirmating this.
You should not expose Delphi specific types, in detail no structured types
(records, classes...). Unlike in Delphi, it's a good idea to wrap ActiveX
parameters in OLEVariants, where e.g. Delphi objects can be passed as
(anonymous) Object types, if ever required. When the user must have access to
properties or methods of an embedded object (control), you can add these
properties and methods to your ActiveX class, and dispatch everything in your
implementation of these exposed methods.
Remember that your users programmatically see a single ActiveX object, whose
detailed structure is both unimportant and of no use, because its components
are not ActiveX components. The users must not know about e.g. Delphi button
types, they only want to be notified when a specific button is pressed.
BTW, there exists a specific Delphi group for OLE, where you'll get more
substancial help. (borland.public.delphi.oleautomation)
Viel Erfolg
DoDi
Ulrich Korndoerfer
VBDis wrote:
>>Thats what one of my main concerns is. The interface uses many native
>>VCL or derived types.
>
> Which interface? The ActiveX class can be totally different from the Delphi
> class. It's up to you to define the ActiveX class, so that the user can access
> your component.
The interface of the VCL component uses many native VCL types (like a
TPanel, a TStringList, bitmap objects and so on). As far as i know, the
Deplphi wizard, which does the ActiveX wrapping, also automatically
creates and implements the ActiveX compatible interface to the VCL
component (besides the other ActiveX interfaces that are necessary for
ActiveX components like IOleInPlaceObject and so on). But the wizard
only automatically implements ActiveX methods for VCL methods, which
uses parameters that have an OLE-compliant type (things like integers,
floats and so on). He does not create ActiveX interface methods for VCL
methods, which have parameters of type TPanel, TStringList and so on.
For those "complex" VCL methods (having "complex" Delphi types) the
correspondent ActiveX method has to be coded by hand. For those
"complex" methods type converters have to be written (from VCL Type to
ActiveX type and back). Now I know the ActiveX side, but I do not know
the Delphi side. I do not know, how a TPanel internally is build and
therefore I do not know how to write a converter to an ActiveX compliant
type (which would have to be a control container in this case, i
assume). I even do not know (at least do not know exactly) what a
TStringList is. I assume it is a collection of name/value pairs where
the names are identifiers for accessing the values which are strings??
This is one of my main concerns. If I go the road to use this Delphi
ThtmViewer component and therefore have to write an ActiveX wrapper for
it, I will have to write some type converters (between Delphi and
ActiveX). But I am not fluent in Delphi. I do not know wether for some
Delphi types (again TPanel comes to mind) this is possible at all and I
do not know how much effort this will cost. It could be simple (eg for a
bitmap object it could be sufficient to retrieve the underlying OS
bitmap handle and deal with this) or it could be complicated, taking
much effort.
Before I go this road, I want to know if it can be done (which depends
mostly on can the type conversions be done) and can it be done with a
reasonable effort.
If anyone is willing to help, tell me. I then will go through the
ThtmViewer docs and make a list of all parameters having types which I
suspect to be complex (mostly Delphi or VCL classes) and post it here.
Then someone could judge if those types can be converted to ActiveX
types and back and how much effort this may be.
>> I would have to write wrappers for each VCL type
>>which is not OLE automation compatible. And this for one who is VCL
>>illiterate :-(. Thank You for affirmating this.
>
> You should not expose Delphi specific types, in detail no structured types
> (records, classes...). Unlike in Delphi, it's a good idea to wrap ActiveX
> parameters in OLEVariants, where e.g. Delphi objects can be passed as
> (anonymous) Object types, if ever required. When the user must have access to
> properties or methods of an embedded object (control), you can add these
> properties and methods to your ActiveX class, and dispatch everything in your
> implementation of these exposed methods.
Yes, this is clear to me. Eg for a ThtmViewer method expecting a
TStringList as one of its parameters I would write a corresponding
ActiveX method accepting an array of strings. Then this method would
have to convert this array of strings to a TStringList and then passes
this TStringList to the corresponding ThtmViewer method.
For a ThtmViewer method having a parameter being of type "descendant of
a TBitmap object" the ActiveX method would accept a Picture object
(having the IPicture interface). I would then create the corresponding
VCL bitmap object and transfer the bitmap bytes from the ActiveX Picture
object to the VCL bitmap object, using the underlying OS bitmap handle.
For a ThtmViewer method expecting a TPanel type parameter, I doubt if i
can transform this. Firstly the TPanel type itself may be hard to
convert. Then, as the sense of a TPanel is to act as a container for
other visual VCL components, those would have to be transformed too.
ThtmViewer accepts html code with a special tag (named widget or the
like). When it parses the html code and comes to this tag, it creates a
TPanel object and does a callback on the embedding application, reaching
out an object reference to this TPanel. The application then can fill
this panel with some controls. The renderer in ThtmViewer then takes
care to position this panel in the flow of the rendered html much like
it would do with a picture. Such an application can embed standard
visual controls into html. Uses are creating a GUI by html code.
> BTW, there exists a specific Delphi group for OLE, where you'll get more
> substancial help. (borland.public.delphi.oleautomation)
Thanks for this info. I think I will give it a try.
> Viel Erfolg
> DoDi
Danke
--
Ulrich Korndoerfer
J French
Ulrich - could you explain what you really want to do
Why do you want to turn a Delphi control into an OCX ?
What control is it that you want to use ?
Ulrich Korndoerfer
J French schrieb:
> Ulrich - could you explain what you really want to do
>
> Why do you want to turn a Delphi control into an OCX ?
> What control is it that you want to use ?
I need a component which at first place can render HTML well. The more
HTML4 and CSS1 is supported by the component, the better. I want to use
it to present data from a database to the user, nicely formatted using
HTML. Data and accompanying pictures are held in memory! Therefore the
control must be able to accept a HTML page and the page resources
(images) from memory.
In second place I want to build parts of the app's GUI with the
renderer. Nowadays there are many apps out there which use HTML for
their GUI. It is kind of dynamic html, where the dynamic part is not
implemented as java script inside the HTML page, but implemented by
callbacks from the renderer to the app that embeds the renderer.
I want to use such a component with VB. So ideally it should be an
ActiveX control.
I have sought for long for such components. Until now I have found 3,
which more or less will fulfill my needs.
One is implemented much like a windows common control from ComCtl32.dll.
It is a standard dll defining a window class and exposing its
functionality by a window procedure. This means: must create the control
as child window with CreateWindowEx, must subclass the parent window for
getting the controls messages and must send messages to the control
instead of calling functions. And I have to work around the fact that a
child window implanted into a VB form is something like sand in a shell.
Eek. An ActiveX wrapper is not available and not planned to be available.
Another one is also implemented like the one from above. It is much more
powerful and claims to get an ActiveX wrapper in the near future. But
even when displaying simple HTML, it has severe render flaws. And this
is version 3 of the control. What the heck did the programmer in all the
years, as some of the render flaws exist since version 1? I think he is
to busy with implementing new features than doing bug fixes. Recently he
has announced that the next version will support scripting, where it
uses its own scripting interpreter. It would be the ideal candidate, if
it would not have those bugs.
The third one is a Delphi component called ThtmViewer from David Baldwin
at www.pbear.com. Its feature list lies between the first and the second
one. It seems to be mature, stable and more or less bug free (at least
when looking at the render results from the accompanying demo app). And
it is fast. And i can not use it, as VB can not use Delphi components,
as you surely know as wanderer between the two worlds. Then I learned
that Delphi has a wizard which can wrap Delphi components with an
ActiveX wrapper. This seems to be a possibility to get it to work for me
in VB. This should be a quick way to make the component available for
VB, especially for the programmer who wrote it. However David Baldwin
will not do this job. He says he had tried some times ago, but has no
plans to do it now.
So may be I can do it on my own. But I do not know Delphi very well. And
the wizard will not do the complete job of wrapping. There is work left
which has to be done "by hand".
Mainly this work left is to convert between Delphi and COM types. Some
methods of the component have parameter types which the wizard can not
automatically convert (he can not implement some converting code). For
these types one would have to write the code for the conversion. But as
said, I do not know Delphi and I do not know the intrinsics of its
types. So how can I write conversion code when I do not know how these
types are internally build?
OK, some of those types may be easy to convert, even if they are Delphi
objects (eg a TStringList). And others may not.
The "killer" type seems to be TPanel. This type is used, when sort of
dynamic html shall be implemented. The TPanel is used by the component
to give the programmer the ability to embed traditional standard
controls, contained in a TPanel, into the html. The renderer then treats
this TPanel much like a picture. He positions it with the flow of the
text. I could give up on wrapping this, as this seems to get complex
work. Then all the rest would be good enough to render html at least.
Truly, all what i really want is to buy a *good* ActiveX HTML rendering
control, drop it on a VB form and on we go.
But there is none. I have to do some work to make those what are
available to work with VB.
So I have to judge which one of the three mentioned above I will use.
The Delphi way at the first glance seemed to be attractive. A wizard
does all and after some mouse clicks I have what i want: an ActiveX
control. Now I know: there is still work left to do. And I wonder, how
much this would be and if an average VB John Doe like me can do this ;-).
Or if somebody could help me with doing this :-)
--
Ulrich Korndoerfer
Maarten Wiltink
news:41F56EB4...@prosource.de...
[...]
> The "killer" type seems to be TPanel. This type is used, when sort of
> dynamic html shall be implemented. The TPanel is used by the component
> to give the programmer the ability to embed traditional standard
> controls, contained in a TPanel, into the html. The renderer then
> treats this TPanel much like a picture.
So the TPanel is just a generic container. Could you make things work
by passing around its window handle? It seems that would let you set
its colour if necessary by sending it Windows messages, and you could
place other controls on top of it.
Groetjes,
Maarten Wiltink
Ulrich Korndoerfer
Maarten Wiltink wrote:
>> The "killer" type seems to be TPanel. This type is used, when sort of
>> dynamic html shall be implemented. The TPanel is used by the component
>> to give the programmer the ability to embed traditional standard
>> controls, contained in a TPanel, into the html. The renderer then
>> treats this TPanel much like a picture.
>
> So the TPanel is just a generic container. Could you make things work
> by passing around its window handle? It seems that would let you set
> its colour if necessary by sending it Windows messages, and you could
> place other controls on top of it.
Principally yes, but I think there will be severe side effects.
If instead of TPanel my app would get an ActiveX-compliant container
like a VB picture box, my app simply could dynamically add some VB
native controls like Editboxes, Comboboxes and so on to the container.
It would set up VB eventhandlers for those and such could react on user
actions on these controls.
If I have to use a TPanel by its hWnd, then I would have to add
dynamically the VB controls to a VB form and then reparent them by
switching their parent hWnd from the VB forms hWnd to the TPanels hWnd.
But already reparenting some VB controls from one VB form to another
has some nasty side effects. Wonder what happens if the new parent is a
TPanel.
But there might be an easier way. When showing HTML (after parsing new
HTML or after resizing), an event is thrown. In this event one could ask
for the position of the TPanel relative to the ThtmlViewer's client
window. Then I could move a VB container over the TPanel.
--
Ulrich Korndoerfer
J French
Are you trying to use Dave Baldwin's THtmlViewer control in VB ?
I certainly don't fancy the idea of adding VB controls to an OCXed
version of that at run time.
J French
<ulrich_wa...@prosource.de> wrote:
>Hi Jerry!
>
>J French schrieb:
>
>> Ulrich - could you explain what you really want to do
>>
>> Why do you want to turn a Delphi control into an OCX ?
>> What control is it that you want to use ?
>
>I need a component which at first place can render HTML well. The more
>HTML4 and CSS1 is supported by the component, the better. I want to use
>it to present data from a database to the user, nicely formatted using
>HTML. Data and accompanying pictures are held in memory! Therefore the
>control must be able to accept a HTML page and the page resources
>(images) from memory.
Hi Ulrich - your post showed up 5 days late on my NG Server
If you are new to Delphi then I must warn you that making OCXes in
Delphi4 is not at all pleasant
I don't really understand the stuff about embedding other controls in
an HTML control - normally that is done with a standard browser and
the controls are in OCXes - not a good idea IMO
Dave Baldwin's THTML is pretty good, well I like it.
I have OCXed a version of it for a client (a software house) and they
seem pretty happy with it.
However it was sheer murder to do - and I am very unhappy with one
aspect of it - it seems to refuse to unload after printing.
Also the version I OCXed is pretty old.
IMO / IME Dave's control is great for embedding in Delphi, but once
OCXed one loses a lot of the advantages - it simply becomes a nice
HTML display utility - unless one is a pretty fair Delphi coder.
Not very helpful I'm afraid
Ulrich Korndoerfer
J French wrote:
> Hi Ulrich - your post showed up 5 days late on my NG Server
>
> If you are new to Delphi then I must warn you that making OCXes in
> Delphi4 is not at all pleasant
>
> I don't really understand the stuff about embedding other controls in
> an HTML control - normally that is done with a standard browser and
> the controls are in OCXes - not a good idea IMO
Basically that can be done with any controls having a window handle and
reacting to the WM_MOVE message by positioning and sizing accordingly.
The renderer needs to know nothing about the control. He just has to
position it following the layout flow when rendering the html. If eg the
renderer window is resized, he has to recalculate the layout and then
has to do the positioning and display of the html blocks. For the
embedded controls he just sends WM_MOVE messages to them. In the case of
the ThtmlViewer however the author has choosen a possibly more powerful
choice: the only control it does recognize is a TPanel (not the hWnd of
a TPanel but the TPanel itself, the renderer creates the TPanel and
hands a reference to it out to the embedding app) and he can handle the
positioning of the TPanel using the TPanel methods in direct. The
embedding app can put on this TPanel any control it likes and such all
controls in the TPanel container are repositioned with the TPanel.
However this approach makes it difficult to embed others than Delpi
controls. An approach using a window handle would be more generic.
> Dave Baldwin's THTML is pretty good, well I like it.
> I have OCXed a version of it for a client (a software house) and they
> seem pretty happy with it.
So you are the one whom i sought for ;-). One who already had done
wrapping it with an ActiveX wrapper.
> However it was sheer murder to do - and I am very unhappy with one
> aspect of it - it seems to refuse to unload after printing.
> Also the version I OCXed is pretty old.
What was "sheer murder"? Creating the default auxiliary interfaces an
ActiveX control has to have (and there are quite a few of them) or
making the native VCL interface available as ActiveX interface? Since
Delphi4 Borland has arrived (after Delphi 5,6,7,8) at Delphi2005, the
wizard doing the base job (creating the default auxiliary interfaces and
implementing at least part of the wrapper interface for the components
VCL native interface) when creating an ActiveX wrapper presumably has
got better. I had played around with C++Builder Version5 (which should
roughly correspond to Delphi5) wrapping an VCL Button, and the wizard
did all of the base job. I got a wrapped button which then I could use
in a VB app (a little VB test app showed this). The main events where
there (especially the Click event), the main generic properties and
events (like Validate, OleDrag, LostFocus and so on) also. Of course,
ThtmlViewer is more complicated than a simple button,
I think with a fairly up to date version of Delphi (lets say at least
Delphi7) the basic jobs needed to be done are done by the wizard. Fine
polishing the VCL interface wrapper than remains to do.
> IMO / IME Dave's control is great for embedding in Delphi, but once
> OCXed one loses a lot of the advantages - it simply becomes a nice
> HTML display utility - unless one is a pretty fair Delphi coder.
Being a nice HTML display utility and HTML printer eventually would be
as first step enough for me. Using the renderer for building the apps
GUI then would be the "candy". This may be achievable too.
Ok, it seems I will not know how much work all the conversion will need
until I have done it. So it does not make longer sense to wait for
someone telling me how much effort this will be. I should just start
doing it and then ask more concrete questions when I got stuck.
So there is my next problem: I do not have a more current version of
Delphi. For Delphi7 there still is the personal version available, but
this one does not give much support on ActiveX wrapping (the help files
on this topic are missing, the wizard is missing). Also its license does
not allow being used for commercial projects. And spending about 1000
Euros for the professional version solely for a one time job seems to be
a little bit of overkill.
> Not very helpful I'm afraid
It was helpful. I appreciate it.
--
Ulrich Korndoerfer
J French
<ulrich_wa...@prosource.de> wrote:
>Hi Jerry!
>
>J French wrote:
>
>> Hi Ulrich - your post showed up 5 days late on my NG Server
>>
>> If you are new to Delphi then I must warn you that making OCXes in
>> Delphi4 is not at all pleasant
>>
>> I don't really understand the stuff about embedding other controls in
>> an HTML control - normally that is done with a standard browser and
>> the controls are in OCXes - not a good idea IMO
>Basically that can be done with any controls having a window handle and
>reacting to the WM_MOVE message by positioning and sizing accordingly.
>The renderer needs to know nothing about the control. He just has to
>position it following the layout flow when rendering the html. If eg the
>renderer window is resized, he has to recalculate the layout and then
>has to do the positioning and display of the html blocks.
Are you talking about re-parenting controls onto (say) a HTMLViewer
window
- or telling the HTMLViewer enough about other controls so that it can
'embed' them into itself
- I think that is what you are after
>For the
>embedded controls he just sends WM_MOVE messages to them. In the case of
>the ThtmlViewer however the author has choosen a possibly more powerful
>choice: the only control it does recognize is a TPanel (not the hWnd of
>a TPanel but the TPanel itself, the renderer creates the TPanel and
>hands a reference to it out to the embedding app) and he can handle the
>positioning of the TPanel using the TPanel methods in direct. The
>embedding app can put on this TPanel any control it likes and such all
>controls in the TPanel container are repositioned with the TPanel.
That makes sense - in VB one would use a Frame or Usercontrol as one
generic 'container'
>However this approach makes it difficult to embed others than Delpi
>controls. An approach using a window handle would be more generic.
True - but a lot more confusing for the normal Delphi coder
>> Dave Baldwin's THTML is pretty good, well I like it.
>> I have OCXed a version of it for a client (a software house) and they
>> seem pretty happy with it.
>So you are the one whom i sought for ;-). One who already had done
>wrapping it with an ActiveX wrapper.
Well - yes and no
In 2001 I discussed with Dave releasing my version to VB'ers
- but since then events have made me not interested
Dave told me that quite a number of people had OCXed his control
>> However it was sheer murder to do - and I am very unhappy with one
>> aspect of it - it seems to refuse to unload after printing.
>> Also the version I OCXed is pretty old.
>What was "sheer murder"? Creating the default auxiliary interfaces an
>ActiveX control has to have (and there are quite a few of them) or
>making the native VCL interface available as ActiveX interface?
The AX Factory was sheer hell
- the code it generated would get 'auto mangled'
It is easy for a really simple control, like a button or a
MessageBlaster
- but for something as complex as Dave's Viewer .....
>Since
>Delphi4 Borland has arrived (after Delphi 5,6,7,8) at Delphi2005, the
>wizard doing the base job (creating the default auxiliary interfaces and
>implementing at least part of the wrapper interface for the components
>VCL native interface) when creating an ActiveX wrapper presumably has
>got better.
D4 did all that
IIRC D5 just introduced the Indy Internet stuff instead of that 'N'
stuff that was distributed with D4
>I had played around with C++Builder Version5 (which should
>roughly correspond to Delphi5) wrapping an VCL Button, and the wizard
>did all of the base job. I got a wrapped button which then I could use
>in a VB app (a little VB test app showed this). The main events where
>there (especially the Click event), the main generic properties and
>events (like Validate, OleDrag, LostFocus and so on) also.
It is a darn site easier and slicker creating an OCX in VB and using
it in Delphi
- I've done both - mainly as tests (I hate OCXes)
>Of course,
>ThtmlViewer is more complicated than a simple button,
And when you have to drill down deep into Dave's code to find why a
recursive GetParent is causing an AV ...
- then you'll know what sweating is all about
>I think with a fairly up to date version of Delphi (lets say at least
>Delphi7) the basic jobs needed to be done are done by the wizard. Fine
>polishing the VCL interface wrapper than remains to do.
Maybe, but the key thing to remember is that Dave writes and tests his
code for Delphi (and C++ Builder)
- he knows of some 'fixes' that need to be made for OCXes
(he told me at least one, and IIRC I sent him a few back)
>> IMO / IME Dave's control is great for embedding in Delphi, but once
>> OCXed one loses a lot of the advantages - it simply becomes a nice
>> HTML display utility - unless one is a pretty fair Delphi coder.
>
>Being a nice HTML display utility and HTML printer eventually would be
>as first step enough for me. Using the renderer for building the apps
>GUI then would be the "candy". This may be achievable too.
Do the Apps /have/ to be in VB ?
While VB is great for running up a quick App, it takes ages forcing it
to do what /you/ want to do.
With Delphi the 'easy stuff' is a bit more fiddly
- but the difficult stuff is really easy
>Ok, it seems I will not know how much work all the conversion will need
>until I have done it. So it does not make longer sense to wait for
>someone telling me how much effort this will be. I should just start
>doing it and then ask more concrete questions when I got stuck.
Yes - that is a smart idea
Make sure you Email Dave and tell him what you are going to do
- he will doubtless send you back a list of tips
>So there is my next problem: I do not have a more current version of
>Delphi. For Delphi7 there still is the personal version available, but
>this one does not give much support on ActiveX wrapping (the help files
>on this topic are missing, the wizard is missing). Also its license does
>not allow being used for commercial projects. And spending about 1000
>Euros for the professional version solely for a one time job seems to be
>a little bit of overkill.
No - and IMO nobody should use the Personal version of Delphi
- the Professional version comes with the source of the VCL
- and that source is essential for understanding how things work
>> Not very helpful I'm afraid
>It was helpful. I appreciate it.
I suggest that you look at coding in pure Delphi
- there are many ways of programming in Delphi
- it is quite easy to avoid all the nightmarish memory management and
pointer stuff (Strings and Dynamic Arrays are well implemented)
What I learnt from Delphi made me change the way I code in VB
Good Luck
Ulrich Korndoerfer
J French wrote:
[...]
>>So you are the one whom i sought for ;-). One who already had done
>>wrapping it with an ActiveX wrapper.
>
> Well - yes and no
> In 2001 I discussed with Dave releasing my version to VB'ers
> - but since then events have made me not interested
> Dave told me that quite a number of people had OCXed his control
Indeed that was one of my hopes: that somebody already did the wrapping
and is willing to share the resulting ocx with me (for money, of course).
[...]
> I suggest that you look at coding in pure Delphi
> - there are many ways of programming in Delphi
> - it is quite easy to avoid all the nightmarish memory management and
> pointer stuff (Strings and Dynamic Arrays are well implemented)
>
> What I learnt from Delphi made me change the way I code in VB
Changing to Delphi is a little bit late for my next project. Some parts
already have been written.
When I leave from VB in the future I think I will take the .NET route
(wether being it C# or VB7 or both).
> Good Luck
Thank you. Also for your infos. I see now that there is even more work
to do than "just" wrapping the component. Your mention of the recursive
GetParent call comes to mind. Or your experience that the wrapped
component does not terminate after printing.
--
Ulrich Korndoerfer