Board index » cppbuilder » Re: why two ide bases

Re: why two ide bases


2003-10-15 08:59:06 PM
cppbuilder33
"Benjamin Pratt" < XXXX@XXXXX.COM >wrote in message
Quote
Why do you suppose Borland has created two seperate IDEs, one for Java/C++
(Jbuilder/CBX) and one for C#/Delphi (C#B/Octane). Surely splitting
development resources in two directions has a cost. Is it worth it?

I think you will find it has a lot to do with hosting live controls in the
form designer... can you imagine how difficult it would be to host a vcl or
.net control in a java based form designer.. the ide needs to be able to
load the .net assemblies or win32 packages, same goes for the java ide
loading beans etc.
--
Regards
Vincent Parrett
Atozed Software www.atozedsoftware.com
---------------
Automate your Build Process with FinalBuilder
 
 

Re:Re: why two ide bases

"Vincent Parrett (Atozed Software)" wrote:
Quote
I think you will find it has a lot to do with hosting live controls in the
form designer... can you imagine how difficult it would be to host a vcl
or
.net control in a java based form designer.. the ide needs to be able to
load the .net assemblies or win32 packages, same goes for the java ide
loading beans etc.
What is the difference between hosting a VCL control and a wxWindow control
in the java based CBX designer?
Peter
 

Re:Re: why two ide bases

"Peter Agricola" < XXXX@XXXXX.COM >wrote in message
Quote
What is the difference between hosting a VCL control and
a wxWindow control in the java based CBX designer?
They are completely different libraries that expose access to the describing
interfaces of controls differently, for starters.
Gambit
 

{smallsort}

Re:Re: why two ide bases

"Remy Lebeau (TeamB)" wrote:
Quote

"Peter Agricola" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...

>What is the difference between hosting a VCL control and
>a wxWindow control in the java based CBX designer?

They are completely different libraries that expose access to the
describing
interfaces of controls differently, for starters.
Yes, but I meant in the context of the message I was replying at.
Both VCL and wxWindows wrap the Win32 api. Ok, they have different
interfaces an RTTI but when CBX can host a live wxWindows control it is also
possible to host a VCL control. The problem Vincent Parrett was refering to
was that it is not possible to live host a native windows control in a java
based IDE. But because Borland manages to host a wxWindows control, a VCL
control must also be possible.
Peter
 

Re:Re: why two ide bases

"Peter Agricola" < XXXX@XXXXX.COM >wrote in
Quote

"Remy Lebeau (TeamB)" wrote:
>
>"Peter Agricola" < XXXX@XXXXX.COM >wrote in message
>news: XXXX@XXXXX.COM ...
>
>>What is the difference between hosting a VCL control and
>>a wxWindow control in the java based CBX designer?
>
>They are completely different libraries that expose access to the
describing
>interfaces of controls differently, for starters.

Yes, but I meant in the context of the message I was replying at.
Both VCL and wxWindows wrap the Win32 api. Ok, they have different
interfaces an RTTI but when CBX can host a live wxWindows control it
is also possible to host a VCL control. The problem Vincent Parrett
was refering to was that it is not possible to live host a native
windows control in a java based IDE.
Is that true? I thought JNI (Java Native Interface) made OS API calls
possible. I know IBM's native-GUI Java library (SWT?) is basically a
wrapper around native controls, unlike SWING/AWT which uses Java
primitives.
Quote
But because Borland manages to
host a wxWindows control, a VCL control must also be possible.


Peter

Bear in mind that the VCL is based on Object Pascal, not C++, and
consequently has dependencies other than just sytem libraries. The VCL
requires a special memory manager (borlndmm.dll) and runtime
(cc3260mt.dll), which may not work in a Java context.
mr_organic
 

Re:Re: why two ide bases

"mr_organic"wrote:
Quote
>Yes, but I meant in the context of the message I was replying at.
>Both VCL and wxWindows wrap the Win32 api. Ok, they have different
>interfaces an RTTI but when CBX can host a live wxWindows control it
>is also possible to host a VCL control. The problem Vincent Parrett
>was refering to was that it is not possible to live host a native
>windows control in a java based IDE.

Is that true? I thought JNI (Java Native Interface) made OS API calls
possible. I know IBM's native-GUI Java library (SWT?) is basically a
wrapper around native controls, unlike SWING/AWT which uses Java
primitives.

>But because Borland manages to
>host a wxWindows control, a VCL control must also be possible.
That was my question. If wxWindows is possible why isn't VCL possible?
Quote
Bear in mind that the VCL is based on Object Pascal, not C++, and
consequently has dependencies other than just sytem libraries. The VCL
requires a special memory manager (borlndmm.dll) and runtime
(cc3260mt.dll), which may not work in a Java context.
Is this an answer or just a guess? <g>
Peter
 

Re:Re: why two ide bases

"Peter Agricola" < XXXX@XXXXX.COM >wrote in message
Quote
Yes, but I meant in the context of the message I was replying at.
Both VCL and wxWindows wrap the Win32 api. Ok, they have
different interfaces an RTTI but when CBX can host a live
wxWindows control it is also possible to host a VCL control.
Perhaps, but to *manipulate* that control, the IDE needs the RTTI. Plus the
public interfaces for accessing the control have to be standardized so that
the form designer can access the controls in the same manner regardless of
which library is used. Otherwise the libraries have to be wrapped in an
extra abstraction layer that each library implements for its specific
controls, the the designer can use the abstraction layer in the same fashion
regardless of implementation.
Gambit
 

Re:Re: why two ide bases

"Peter Agricola" < XXXX@XXXXX.COM >wrote in message
Quote
That was my question. If wxWindows is possible why isn't VCL possible?
Because wxWindows is C++, for starters. Lets also not forget that any
current designer for wxWindows is going to be wxWindows-specific. In order
to support multiple libraries/frameworks in a common designer, much effort
is needed to abstract them.
Gambit
 

Re:Re: why two ide bases

"Remy Lebeau (TeamB)" wrote:
Quote
"Peter Agricola" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...

>Yes, but I meant in the context of the message I was replying at.
>Both VCL and wxWindows wrap the Win32 api. Ok, they have
>different interfaces an RTTI but when CBX can host a live
>wxWindows control it is also possible to host a VCL control.

Perhaps, but to *manipulate* that control, the IDE needs the RTTI. Plus
the
public interfaces for accessing the control have to be standardized so
that
the form designer can access the controls in the same manner regardless of
which library is used. Otherwise the libraries have to be wrapped in an
extra abstraction layer that each library implements for its specific
controls, the the designer can use the abstraction layer in the same
fashion
regardless of implementation.
My question was not how Borland makes CBX framework agnostic. I still don't
see why a java based IDE wich can host a live wxWindows control can't host a
VCL control ( BTW not at the same time).
Peter
 

Re:Re: why two ide bases

"Remy Lebeau (TeamB)" wrote:
Quote

"Peter Agricola" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...

>That was my question. If wxWindows is possible why isn't VCL possible?

Because wxWindows is C++, for starters. Lets also not forget that any
current designer for wxWindows is going to be wxWindows-specific. In
order
to support multiple libraries/frameworks in a common designer, much effort
is needed to abstract them.
This thread is not about framework agnostic IDE's.
Peter
 

Re:Re: why two ide bases

"Peter Agricola" < XXXX@XXXXX.COM >wrote in message
Quote
I still don't see why a java based IDE wich can host a live
wxWindows control can't host a VCL control
It is not a matter of "can" vs. "can't". In order to host a control, the
control itself has to be instantiated. The designer has to know how to do
that in the first place, and that is framework-specific. It also needs to
know how to host the control once it has been created, to manipulate it and
specify how controls relate to each other. Again, that is framework
specific as well. Right now, CBX only knows about the wxWindows framework.
It has no concept of the VCL. In order to host VCL controls, the designer
would need to be updated to support VCL's specific details regarding its
controls. Or, as I suggested earlier, to introduce an abstraction layer so
that the designer does not have to directly know the details about each
specific framework. Either way, those are not in place at this time, but
that is not to say that it won't be put into place later on. For the time
being, the current designer (which, btw, is just a preview anyway) is
wxWindows-specific, as far as I know.
Gambit
 

Re:Re: why two ide bases

"Remy Lebeau (TeamB)" < XXXX@XXXXX.COM >wrote in
message news:3f8ee1f7$ XXXX@XXXXX.COM ...
Quote
For the time
being, the current designer (which, btw, is just a preview anyway) is
wxWindows-specific, as far as I know.
I've done some reverse engineering. It's some of both. It *appears* to
me that ...
There is a generalized component designer framework written in Java that
handles both visual and non-visual components. You implement a set of
interfaces that provide the designer information about properties,
events, icons, etc.
There is a specific wxWindows implementation of those interfaces that
talks to a web service (look for a wxwserv process when C++BuilderX is
running) that does all the actual manipulation of the live components.
In fact, what you see in the design viewer in CBX is not actually a live
component but rather an image that looks like the live component. The
web service sends back a "picture" of the component to CBX, and that's
what gets displayed.
Obviously VCL could be supported by a similar web service, but doing so
is probably a non-trivial undertaking.
--
Gillmer J. Derge (TeamB)
 

Re:Re: why two ide bases

Gillmer J. Derge (TeamB) wrote:
[snip]
Quote
Obviously VCL could be supported by a similar web service, but doing so
is probably a non-trivial undertaking.

Yeah - that's a pretty cool design. It seems it's possible that one can
have a designer running on the other side of the world.
I think if that's the final design, Borland should document it
properly, so people can start building cool designers ;)
.a
 

Re:Re: why two ide bases

"Alex Bakaev [TeamB]" < XXXX@XXXXX.COM >wrote in message
Quote
I think if that's the final design, Borland should document it
properly, so people can start building cool designers ;)
I agree. In fact, I'd like to see them go so far as to distribute the
source code to the server side of the web service as an example. It's
useless without the client side (which could remain as obfuscated Java),
so I don't think it wouldn't hurt sales. In fact, it could arguably
help, since a VCL designer project at SourceForge could more or less put
an end to all the issues of whether CBX will or won't support VCL and
why or why not.
--
Gillmer J. Derge (TeamB)
 

Re:Re: why two ide bases

"Gillmer J. Derge (TeamB)" < XXXX@XXXXX.COM >wrote in message
Quote
There is a generalized component designer framework written in
Java that handles both visual and non-visual components. You
implement a set of interfaces that provide the designer information
about properties, events, icons, etc.
Ok, that makes sense and would be logical considering Borland's claim that
CBX is framework-agnostic now, and the fact that there is going to be
sessions at BorCon regarding how to plug in frameworks into CBX, so I would
imgine that there would have to already be some kind of abstraction layer in
place for it.
Quote
There is a specific wxWindows implementation of those interfaces
that talks to a web service (look for a wxwserv process when
C++BuilderX is running) that does all the actual manipulation of
the live components.
Ok, that would fall under the realm of internal implementation details for
the wxWindow-specific implementation of the designer abstraction layer.
Quote
In fact, what you see in the design viewer in CBX is not actually
a live component but rather an image that looks like the live
component. The web service sends back a "picture" of the
component to CBX, and that's what gets displayed.
Ouch. I'm sure that has to pay a cost in transmission traffic and image
overhead over time, especially as "windows" get more complex with additional
"components" being added to them.
Gambit