John Kaster in Milwaukee
John Jacobson
use D2006 every day and went mainly for the purpose of hoping to win an
architect version of D2006. But I ended up learning quite a few things, like
about TFlowControl, and several other goodies. Personally I think JK should
do more to emphasize how easy D2006 makes it to share code between Win32 and
.NET through the wrappers created by wizards in D2006, but he did show how
helper classes enabled CF development so he kind of was there, in a
round-about manner. (The problem with D2006 is that there is so much new
stuff in there that it is impossible to cover more than a small fraction of
it in a mere 3.5 hours.)
There was a good crowd, I thought. A few people in the crowd were visibly
impressed by what I and all the rest of us D2006 users have come to accept
as normal. If DevCo can get D2006 more exposure, they could maker a real
splash. A few of us asked questions about the DevCo sale. JK had started his
presentation by addressing it head-on, which is probably the most sensible
thing he could do. I have to be honest, though I asked him a couple of
rather impertinent questions on this topic, he didn't miss a beat. I was not
thrilled at the answer to the question about what plans were in place in
case no investors offer what Borland thinks DevCo is worth, which was
basically, in so many words, to paraphrase the quote "failure is not an
option". I personally would like to see that Borland has some kind of
contingency plan in place for Delphi, but, hey, there are no guarantees in
life.
In retrospect I realize that I am often too skeptical in general. My
skeptical tendencies have made me pessimistic about this whole DevCo sale,
but after seeing JK talking enthusiastically about the goodies in D2006
right now, and the roadmap going forward (which, among many other things,
had VCL for C# in it, IIRC), I feel much more optimistic about Delphi's
long-term future. In addition, it is hard not to get excited about D2006
after seeing a 3.5 hour demo and realizing that JK barely scratched the
surface of what this tool can do.
Better inter-language interfacing within the same project is something they
are working on or thinking about, so that you ought to be able to eventually
mix C++ and Delphi code in the same project and have Delphi take care of all
the plumbing. If you take a good look at the project options in D2006 you
see a tittlating suggestion of this as well, in the form of a disabled
checkbox labelled "Generate All C++ Builder Files". Presumably this checkbox
will be enabled in the future.
I also noticed an interesting statement or slip of the tongue when JK was
talking about the DevCo spin-off and why it was a good idea. Now, maybe I
misheard this, but I could swear that I thought I heard JK use the phrase
"What Microsoft and Borland wanted" when referring to the plans/vision for
ALM at Borland and how it differs from what DevCo wants. There are those
here on non-tech who have speculated that Borland may be priming the pump
for a sale or acquisition not so much of the IDE's as the ALM business, to
someone like MSFT. This little slip of the tongue or simple statement would
appear to bear this out. Now, before anyone runs for the hills crying that
MSFT is buying Borland, it is important to remember that this could have
been a meaningless mistake that really has nothing to do with any of this
stuff, and maybe more to do with accidental incidentals.
Well, that's my wrap-up of the meeting. I sure hope DevCo gets some good
financing and can build on the excellent foundation laid in D2006. I'm
reminded every day what a superb tool it is.
[JK--if you are reading this, I now remember what question I wanted to ask
but forgot, and that is if DevCo had any plans on possibly replacing
Together with a more robust and less resource-intensive
modelling/refactoring engine like ModelMaker. I think I speak for more than
just myself when I say that Together seems to be the thorn in Delphi's
side.]
Joe Hendricks
> ...if DevCo had any plans on possibly replacing
> modelling/refactoring engine like ModelMaker.
> I think I speak for more than just myself when I say
> that Together seems to be the thorn in Delphi's side.
You certainly speak for me ! Especially now that ModelMaker
has full ECO3 modeling working, including state machines.
Lean, fast & flexible !
JoeH
Dave Nottage [TeamB]
> ..how easy D2006 makes it to share code between Win32 and .NET
> through the wrappers created by wizards in D2006..
I'd be interested in the details of that.
--
Dave Nottage [TeamB]
Have questions?: http://www.catb.org/~esr/faqs/smart-questions.html
Want answers?: http://support.borland.com
Lauchlan M
But don't they still use Together for auditing and metrics, design patterns,
refactoring, etc?
I can imagine how ECO might use ModelMaker instead of Together, but I don't
see how it helps them ditch together altogether (even if they want to).
Lauchlan M
Roddy
"John Jacobson" <jake@j[nospam]snewsreader.com> wrote in message
news:441a55cd$1...@newsgroups.borland.com...
> If you take a good look at the project options in D2006 you see a
> tittlating suggestion of this as well, in the form of a disabled checkbox
> labelled "Generate All C++ Builder Files". Presumably this checkbox will
> be enabled in the future.
>
It works today, and it's for IDE component packages. You can -
theoretically - build IDE component packages for both C++ and Delphi from
the same Delphi project. I say "theoretically", because many 3rd party
components need massaging to generate useful C++ header files... What you
can't do is use C++ components in Delphi projects.
- Roddy
![Jonathan Neve[Microtec]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjUem5QTZ0lji1cyF1UQQSPHiId9LITt3SLe8e7HF_NHyhl0mA=s40-c)
Jonathan Neve[Microtec]
> It works today, and it's for IDE component packages. You can -
> theoretically - build IDE component packages for both C++ and Delphi
> from the same Delphi project. I say "theoretically", because many 3rd
> party components need massaging to generate useful C++ header
> files... What you can't do is use C++ components in Delphi projects.
Any information on how exactly to do that?
I haven't looked at it in detail yet, but I noticed that the Delphi
2006 packages I made for CopyCat didn't work in C++ mode, so if there's
some way of getting one package to work for both languages, I'd be very
interested.
Thanks!
--
Best regards,
Jonathan Neve
_______________
CopyTiger - advanced database replicator for Interbase/Firebird!
Web : http://www.microtec.fr/copycat/ct
_______________________________________
CopyCat - database replication components for Delphi/C++Builder!
Web : http://www.microtec.fr/copycat/cc
Pete Fraser
this will make Borland's task of C++ refactoring much
easier (which I will like)
Rgds Pete
"Lauchlan M" <LMackinnonAT_NoSpam_ozemailDOTcomDOTau> wrote in message
news:441a...@newsgroups.borland.com...
Roddy
news:xn0eju25c1l0b6u...@forums.borland.com...
>> It works today, and it's for IDE component packages. You can -
>> theoretically - build IDE component packages for both C++ and Delphi
>> from the same Delphi project. I say "theoretically", because many 3rd
>> party components need massaging to generate useful C++ header
>> files... What you can't do is use C++ components in Delphi projects.
>
> Any information on how exactly to do that?
It's been asked regularly in cppbuilder.non-tech : Here's what Jeff Overcash
wrote earlier today...
"Totally uninstall the package (and maybe restart the IDE). Then in the
package
options go to the linker options of the package and select the Generate all
C++
Files. Rebuild and install the package.
It is important that if you have the package already installed and have not
selected this option you must uninstall it before rebuilding everything as
certain registry entries don't seem to be made when you just rebuild the
package
as opposed to installing the package."
That sums it up. The usual behaviour if you cock up is that the package
appears to install, but the components don't show up in the palette under
BCB personality.
Somewhere, there's a Jedi document describing best practice for writing
Delphi components that port smoothly to BCB. but I can't find it :(
- Roddy
Jonathan Neve[Microtec]
> It's been asked regularly in cppbuilder.non-tech : Here's what Jeff
> Overcash wrote earlier today...
>
> "Totally uninstall the package (and maybe restart the IDE). Then in
> the package options go to the linker options of the package and
> select the Generate all C++ Files. Rebuild and install the package.
>
> It is important that if you have the package already installed and
> have not selected this option you must uninstall it before rebuilding
> everything as certain registry entries don't seem to be made when you
> just rebuild the package as opposed to installing the package."
>
> That sums it up. The usual behaviour if you cock up is that the
> package appears to install, but the components don't show up in the
> palette under BCB personality.
Excellent, I didn't realise it was as simple as that!
> Somewhere, there's a Jedi document describing best practice for
> writing Delphi components that port smoothly to BCB. but I can't find
> it :(
Yes, I've seen that document before, though I don't know if it has been
updated for BDS 2006.
Bruce McGee
> Personally I think JK should do more to emphasize how easy D2006
> makes it to share code between Win32 and .NET through the wrappers
> created by wizards in D2006
And even without wrappers or wizards. It's one of Delphi's strongest
features. I hope DevCo brags this up a lot more.
> to paraphrase the quote "failure is not an option".
Sounds good to me. You can bet that there's a plan, even if they
aren't sharing it out loud. I know I have a plan if this all goes
south. It just isn't my first choice.
> In retrospect I realize that I am often too skeptical in general.
:)
> (which, among many
> other things, had VCL for C# in it, IIRC)
That would be very cool, but are you sure about this one?
Glad it was a good presentation. Do you guys normally go for a drink
after the meetings? That's where the really interesting discussions
happen.
--
Regards,
Bruce McGee
Glooscap Software
Jon Robertson
> Tonight JK gave a D2006 presentation, and as usual he did a superb
> job. I use D2006 every day and went mainly for the purpose of hoping
> to win an architect version of D2006.
> (The problem with D2006 is that there is so much new stuff in
> there that it is impossible to cover more than a small fraction of it
> in a mere 3.5 hours.)
I would love to get one of these sessions on video. Anders Ohlsson
brought the Delphi Tour to Little Rock at the Little Rock Tech Expo.
Unfortunately, he only had a one hour time slot. There's so little you
can cover in an hour.
Although, my manager did win an architect version of D2006. ;)
--
Jon Robertson
Borland Certified Advanced Delphi 7 Developer
MedEvolve, Inc
http://www.medevolve.com
John Jacobson
<xn0ejty8f...@newsgroups.borland.com>
> Glad it was a good presentation. Do you guys normally go for a drink
> after the meetings?
I went home, took a shower, ate and went to bed after writing the OP in this
thread. I have no idea if JK and Dan Miser did anything, it was already around
10PM by the time the meeting had ended.
--
***Free Your Mind***
Posted with JSNewsreader Preview 0.9.4.2155
John Jacobson
> What you
> can't do is use C++ components in Delphi projects.
Actually, there is a way to do this, but it is not very obvious or easy.
John Jacobson
<441a64fd$1...@newsgroups.borland.com>
> I'd be interested in the details of that.
Indeed. The only way I discovered it was by simply fiddling around in Delphi.
They definitely need to advertise this more, or at least give it some BDN
cycles.
Dave Nottage [TeamB]
> ..at least give it some BDN cycles..
That's my plan.
Captain Jake
> And even without wrappers or wizards. It's one of Delphi's strongest
> features. I hope DevCo brags this up a lot more.
Yeah, I think this is good selling point because of all the existing code
out there that needs to play nice with new .NET code, and vice versa. How
does the D2006 capabilities in this regard compare to VS2005? I have a
personal edition of VS2005 but I haven't had a chance yet to look around
enough to see if this kind of stuff is in VS2005.
Wayne Niddery [TeamB]
>
> [JK--if you are reading this, I now remember what question I wanted
> to ask but forgot, and that is if DevCo had any plans on possibly
> replacing Together with a more robust and less resource-intensive
> modelling/refactoring engine like ModelMaker. I think I speak for
> more than just myself when I say that Together seems to be the thorn
> in Delphi's side.]
I think rather than replacing it, they can more easily just work out the
necessary fixes and improvements - Together powers Delphi's refactoring
features as well as modelling. For the modelling part, I believe it is
already possible to use ModelMaker in place of Together, even for ECO.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: http://www.logicfundamentals.com/RADBooks.html
"In a tornado, even turkeys can fly." - unknown
Joe Hendricks
> For the modelling part, I believe it is
> already possible to use ModelMaker
> in place of Together, even for ECO.
Yes, I am doing just that in my D2006Arch
and finding the speed greatly improved.
JoeH
Serge Dosyukov (Dragon Soft)
I thought to write one myself, but I was waiting for you ;o)
Thank you for presentation sum up.
First, it is great to see John K again as well as see people who you know
from conversations here in person.
I said "Hi" to Dan... ;o)
It is great to see confidence of the people of DevCo in their and in our
future.
Even though I do use BDS2006 every day, I found some information which I
might missed and it is good to have sum about not only features of IDE but a
strong recognition of the work of the community to improve the product -
Jeremy and Chee Wee - you and your work were under spot light there. Great
job (as usual ;o))
> I also noticed an interesting statement or slip of the tongue when JK was
> talking about the DevCo spin-off and why it was a good idea. Now, maybe I
> misheard this, but I could swear that I thought I heard JK use the phrase
> "What Microsoft and Borland wanted" when referring to the plans/vision for
I wouldn't go there to deep though. Since MS discussion was just before that
and might just being put by accident there.
Roddy Pratt
>
>> Somewhere, there's a Jedi document describing best practice for
>> writing Delphi components that port smoothly to BCB. but I can't find
>> it :(
>
> Yes, I've seen that document before, though I don't know if it has been
> updated for BDS 2006.
It's here. It does need some updating for D2006...
http://homepages.borland.com/jedi/jvcl/BCB%20Compatibility%20Guide.html
- Roddy
Bruce McGee
You haven't seen any of my rants on this? I guess I've being too low
key. :)
Delphi has always been surprisingly compatible between versions of the
IDE and and even between platforms, which makes my life easier. It
also has more .Net interop features than any other language, including
C#. I expect this to continue in Highlander with .Net 2.0 support
and beyond.
I've said it before and I'll say it again. I prefer tools that give me
more options.
http://cc.borland.com/Item.aspx?id=22688
Unmanaged exports. Run .Net code from Win32 applications without COM
interop. Delphi and managed C++ support these, but C# doesn't.
http://cc.borland.com/Item.aspx?id=23615
Virtual Library Interfaces (VLI). Run Win32 code from .Net
applications without PInvoke. Not sure if any of the other .Net
languages support something similar.
http://cc.borland.com/Item.aspx?id=22700
Game of Life. A single source VCL project that builds equally well in
Delphi and Delphi for .Net.
http://cc.borland.com/Item.aspx?id=22689
Magic 8 Ball. A single business object and examples of it being used
in VCL, VCL.Net, Delphi Winforms, C# and VB.Net applications. You
could probably do something similar with C++ and maybe VB if you're
careful. C#? Not so much.
http://cc.borland.com/Item.aspx?id=22691
We all know that Delphi for .Net can cheerfully use the FCL and
Winforms. For good measure, here's an example of C# using a VCL class.
Of course, I don't want to sell C# short. I'd be happy to hear about
any C# interop features that I've missed.
Dave Nottage [TeamB]
> The only way I discovered it was by simply fiddling around in Delphi.
I'd be interested to know what "fiddling" you did.
Brad White
> Captain Jake wrote:
>
>> "Bruce McGee" <bmc...@glooscap.com> wrote in message
>> news:xn0ejty8f...@newsgroups.borland.com...
>> > And even without wrappers or wizards. It's one of Delphi's
>> > strongest features. I hope DevCo brags this up a lot more.
>>
>> Yeah, I think this is good selling point because of all the existing
>> code out there that needs to play nice with new .NET code, and vice
>> versa. How does the D2006 capabilities in this regard compare to
>> VS2005? I have a personal edition of VS2005 but I haven't had a
>> chance yet to look around enough to see if this kind of stuff is in
>> VS2005.
>
> IDE and and even between platforms, which makes my life easier. It
> also has more .Net interop features than any other language, including
> C#.
>
> more options.
>
Bruce, this is great stuff.
--
Thanks,
Brad.
John Jacobson
"Dave Nottage [TeamB]" <rot13....@enqfbsg.pbz.nh> wrote in message
> John Jacobson wrote:
>
>> The only way I discovered it was by simply fiddling around in Delphi.
>
> I'd be interested to know what "fiddling" you did.
I have no idea how well this works when you get down and dirty and start
actually using these objects, yet. If I do more fiddling around and find out
anything interesting, Ill post it here. I highly recommend looking at the
generated code, it is very interesting. Obviously someone at Borland put a
lot of work into this automatic interop support, so it is a real shame that
almost nobody knows it even exists. Anyway, here we go...
To Import a .NET assembly into Win32 in D2006 as COM object:
Component|Import Component|Import .Net Assembly
...it then creates a wrapper class for using the .NET assembly as if it
were a COM object. If you do this while you have a Win32 C++ project open it
creates C++ code for the wrappers, if you do it from a Win32 Delphi project
it creates Delphi code for the wrappers. Presumably you then instantiate and
use it like you would any other COM object.
To import a Win32 COM object into a VCL.NET project in D2006:
Right-click on the VCL.NET project in the project manager, choose "Add
Reference", choose the tab for installed COM objects, select a COM object,
click OK. The IDE will add a reference called
InterOp.NameOfTheComObjectHere.dll. You have to manually add
NameOfTheComObjectHere to your uses clause.
Here's an example of a VCL.NET unit using an imported ABUILib COM object I
found in my list of installed COM components on my machine:
unit Unit5;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, ABUILib, System.ComponentModel, Borland.Vcl.StdCtrls;
type
TForm5 = class(TForm)
Button1: TButton;
procedure Button1Click(Sender: TObject);
private
{ Private declarations }
public
{ Public declarations }
end;
var
Form5: TForm5;
implementation
{$R *.nfm}
procedure TForm5.Button1Click(Sender: TObject);
var cl: ABUIClass;
begin
cl := ABUIClass.Create;
cl.Recalc; //<---code completion works here!
end;
end.
John Jacobson
> To import a Win32 COM object into a VCL.NET project in D2006:
>
> Right-click on the VCL.NET project in the project manager, choose "Add
> Reference", choose the tab for installed COM objects, select a COM object,
> click OK. The IDE will add a reference called
> InterOp.NameOfTheComObjectHere.dll. You have to manually add
> NameOfTheComObjectHere to your uses clause.
>
> Here's an example of a VCL.NET unit using an imported ABUILib COM object I
I should point out that this functionality also exists for WinForms projects
as well, whether they are written in Delphi or C#.
I honestly don't see how COM interop could be any easier, except maybe if it
automatically did something like this for regular non-COM VCL components.
John Jacobson
> I should point out that this functionality also exists for WinForms
> projects as well, whether they are written in Delphi or C#.
Also, VS2005 has the same C# interop wizard for easily pulling COM objects
into .NET 2.0.
Dave Nottage [TeamB]
> To Import a .NET assembly into Win32 in D2006 as COM object:
Oh.. not exactly what I was after at the moment, however I'll stow it
away for future reference <g>
John Jacobson
> http://cc.borland.com/Item.aspx?id=22688
> Unmanaged exports. Run .Net code from Win32 applications without COM
> interop. Delphi and managed C++ support these, but C# doesn't.
I noticed that chapter 16 of Xavier Pacheco's book "Delphi for .NET
Developers Guide" covers this, and offers the interesting suggestion that
Delphi for .NET can be used to create unmanaged exports for poorer kids like
C#, so they can be accessed from Win32 too. One caveat that X mentions is
that this only works for global functions and procedures, which makes sense
since this technique is syntactically identical to regular Win32 DLL
exports, but gloms them all together into one class. I suppose one could
export classes across the boundary by flattening them on the .NET side and
reconstructing them on the Win32 side, but this takes work that should make
one wonder why they are not just using COM interop instead then. I guess
part of the answer to that could be performance. It would be interesting to
benchmark unmanaged exports against COM interop.
>
> http://cc.borland.com/Item.aspx?id=23615
> Virtual Library Interfaces (VLI). Run Win32 code from .Net
> applications without PInvoke. Not sure if any of the other .Net
> languages support something similar.
Wow, that is pretty cool. Presumably, this ought to work for Delphi for .NET
and Win32 C++ Builder code as well, since it appears to rely on virtual
tables; which I seem to remember being the same between Delphi and C++, at
least it was several years ago when a similar method was discussed for
interfacing Win32 C++ and Win32 Delphi code without using COM (see Tex and
X's DDG). Don't know if they are still the same now though. Another
interesting thing for someone to try.
I wonder if this technique might be a bit risky, since there may be no
guarantee that DevCo wil maintain the same layout for the Win32 and .NET
virtual tables in the future?
> http://cc.borland.com/Item.aspx?id=22691
> We all know that Delphi for .Net can cheerfully use the FCL and
> Winforms. For good measure, here's an example of C# using a VCL class.
That's a non-visual VCL.NET class, it should be noted. Presumably, this is
not going to work for a visual VCL.NET control, since they assume they are
being placed on a TComponent, not a Winform? But non-visual classes like
TThread, TSynchronize, TMultiReadExclusiveWriteSynchronizer, TIniFile,
TRegistry, etc. are fine. How many of the non-visual classes in the VCL.NET
do not have equivalents in .NET though? What is perhaps more interesting, to
me anyway, is that *Indy* has .NET assemblies sitting in the Borland common
assemblies directory that can be used in C#, whether in VS2005 or D2006.
But, perhaps it is possible to *dynamically* create a VCL.NET TForm,
dynamically populate it with VCL.NET controls and show it, all from within
C# this way? (I know there is no way to fake it out at design time,
obviously) Another thing to try, I suppose.
I have a lot of playing to do this weekend...
Bruce McGee
> I noticed that chapter 16 of Xavier Pacheco's book "Delphi for .NET
> Developers Guide" covers this, and offers the interesting suggestion
> that Delphi for .NET can be used to create unmanaged exports for
> poorer kids like C#, so they can be accessed from Win32 too.
That interesting suggestion is part of the point. When the feature was
first introduced, I remember someone asking if you could use this to
give Win32 apps access to the entire .Net framework. The answer was
that it would be fairly difficult to prevent it. :)
Another caveat is that the unit that exports the methods is flagged as
unsafe.
I have a lingering impression from when I first started learning .Net
that COM Interop adds overhead and performance penalties compared to
using PInvoke in the other direction. I'd love to see someone
benchmark this against unmanaged exports. If nobody does, I might give
it a go. I don't want to put it on my Todo list. That'll just mean I
might never get to it. :)
> That's a non-visual VCL.NET class, it should be noted. Presumably,
> this is not going to work for a visual VCL.NET control, since they
> assume they are being placed on a TComponent, not a Winform? But
> non-visual classes like TThread, TSynchronize,
> TMultiReadExclusiveWriteSynchronizer, TIniFile, TRegistry, etc. are
> fine. How many of the non-visual classes in the VCL.NET do not have
> equivalents in .NET though? What is perhaps more interesting, to me
> anyway, is that Indy has .NET assemblies sitting in the Borland
> common assemblies directory that can be used in C#, whether in VS2005
> or D2006.
>
> But, perhaps it is possible to dynamically create a VCL.NET TForm,
> dynamically populate it with VCL.NET controls and show it, all from
> within C# this way? (I know there is no way to fake it out at design
> time, obviously) Another thing to try, I suppose.
>
> I have a lot of playing to do this weekend...
True, but the real point is that Delphi code that can be used in Delphi
for Win32 and Delphi for .Net can also be used by other .Net languages.
And I'm not talking about fragile classes that you have to be very
careful about how they're built. Every once in a while someone tries
to infer that Delphi generates code that is somehow inferior or less
pure than Visual Studio. Of course, it doesn't, but this is a working
example.
It might be worth publishing an example VCL.Net application that
creates and uses a Winform and a Delphi or C# Winforms app that does
the same with a VCL.Net form. I think I remember John Kaster showing
off the second one back around the time of Delphi 8. Mixing VCL
components on a Winform and the other way around might be tougher. The
import tool that wraps Winforms components so they can do this didn't
work very well in Delphi 8, but I haven't tried it recently.
Which brings me to a mild rant. A lot of these features have been in
Delphi for a while, and have been mentioned in books, articles, blog
entries and news group posts (thanks, guys), but why isn't Borland
talking about them? Why can't I go to the web site and immediately see
the features that make Delphi stand out from the competition? Quiet
competence has its place, but now is not the time to let misinformed
newsgroup posters shape public perception. Now is the time to be
bragging.
On the bright side, Delphi has always done well in spite of Borland's
near pathological marketing neglect. Now, imagine it with the same
(and likely much better) technical merits, except Devco actually tells
people about it. A friend asked me yesterday how I could imagine
Delphi's market share increasing. This is how.
David Clegg
> It might be worth publishing an example VCL.Net application that
> creates and uses a Winform
FWIW, I've done this (of sorts) with an ECO VCL.NET app. It invoked the
default ECO AutoContainer to show an ECO object instance, and this
AutoContainer implementation is a WinForm.
--
Cheers,
David Clegg
dcl...@gmail.com
http://cc.borland.com/Author.aspx?ID=72299
QualityCentral. The best way to bug Borland about bugs.
http://qc.borland.com
"Marge, when I join an underground cult I expect a little support from
my family." - Homer Simpson
John Kaster (Borland)
> And as Together can do C++ and modelmaker can't
> this will make Borland's task of C++ refactoring much
> easier (which I will like)
Right now, we can't use Together's C++ support for refactoring because
Together's C++ analysis engine does not understand the Borland C++
compiler's extensions for Properties, Methods, and Events, which are
what make C++'s consumption of VCL and creation of C++ VCL components
possible.
--
John Kaster http://blogs.borland.com/johnk
Features and bugs: http://qc.borland.com
Get source: http://cc.borland.com
If it's not here, it's not happening: http://ec.borland.com
John Kaster (Borland)
> [JK--if you are reading this, I now remember what question I wanted
> to ask but forgot, and that is if DevCo had any plans on possibly
> replacing Together with a more robust and less resource-intensive
> modelling/refactoring engine like ModelMaker. I think I speak for
> more than just myself when I say that Together seems to be the thorn
> in Delphi's side.]
Sorry, just caught this now. We are certainly open to other modelling
tools as part of DevCo, and I think I *did* use something like that as
an example when talking about DevCo's future flexibility.
John Kaster (Borland)
> I would love to get one of these sessions on video.
I hope to have time to record one of the presentations back here in
Scotts Valley. I always digress to take questions during my talks, so I
don't think the recording of a live presentation would be as
information rich.
John Kaster (Borland)
> I hope DevCo brags this up a lot more.
I'm happy to pay for a BDN article on it, at least.
Bruce McGee
> I'm happy to pay for a BDN article on it, at least.
ok
John Jacobson
<44431687$1...@newsgroups.borland.com>
> We are certainly open to other modelling
> tools as part of DevCo, and I think I *did* use something like that as
> an example when talking about DevCo's future flexibility.
It seems to me that it ought to be quite doable. Recently I've been working on
a parser, written in C#, for Delphi code, and it has given me an idea of the
scope of a project that would do refactoring and modeling. It seems to me that
the scope is easily within the capabilities of a group like DevCo. And if you
start from a project like CodeWrench, it ought to be even easier.
Of course, having said that, I should point out that the Together-based stuff
in Pro seems to finally be working fine on this home PC (2GB RAM, D2006 update
#2).
--
***Free Your Mind***
Posted with JSNewsreader Preview 0.9.4.2283