Pondering the dev tool landscape from an outsider
Gareth Conner
My apologies in advance, this is a somewhat lengthy post...
I've been lurking around these newsgroups for some months and purchased
a Turbo Delphi Pro license a little while ago. I've had some time to
play with Delphi, and I'm now mired in a quandry trying to decide my
best path for continuing development on an existing VB6 application.
I am not what you would consider a professional programmer, since I
lack any formal training (other than a couple of comp sci classes I
took while earning my degree in theatre!). However, the company I run
makes its business by developing and selling Ethernet-enabled motor
control devices and control software for use in live entertainment
(musical performances, etc.). We split our time between developing
electronic gadgets, firmware, machinery, and desktop software.
Our main desktop software was originally developed in VB6, and has
served us pretty well for the past several years. However, we are
faced with updating the software for the next major version and I'm
trying to make the most prudent decision regarding which platform to
use. This is a process I've been looking at casually for well over a
year, and has been back-burnered a number of times as more pressing
needs required attention. I've been seriously considering: Java with
the Netbeans RCP, Delphi, and VB/C# .Net.
Over a couple of months of sporadic work, I've gotten about 20% into a
Java port leveraging the Netbeans RCP. Though I'm somewhat pleased
with the result, I'm still plagued with enough doubt to lead me in a
vicious circle of constantly evaluting other platforms. As I've read
posts from other folks in this newsgroup, it's apparent that many
people here are well experienced in all of the same platforms I'm
considering. I'm hoping to hear some words of wisdom to help me put my
doubts to an end and forge forward with development on the best path.
The application requirements can be met by any of the tools in
question. It controls a network of motors via TCP sockets. There is a
fair amount of background processing happening all the time, so the app
must be multi-threaded (currently implemented as an ActiveX COM server
in VB version). The main GUI isn't flashy, but has a tree view, grid
view, and a 2d real-time schematic that depicts the scenery as it moves
around on stage.
So, from what I've learned throughout my meanderings the tools stack up
like this:
***Java (with Netbeans RCP)***
Pros:
* Extremely well documented. Easy to find answers to questions.
* Vast class library. Many times things you want to do, are already
implemented (if you can find them).
* Swing is a very flexible & powerful GUI toolkit with a well-designed
API.
* Cross platform.
* Garbage collection relieves some responsibility.
* Easy sockets & multi-threading.
Cons:
* Somewhat convoluted. As a gut reaction, it takes 2x-3x the amount of
code to get something done compared to VB. I'm sure it's cleaner
programming, but every task requires a long chain of classes &
interfaces.
* Swing is almost *too* flexible. I've been using the Netbeans Rich
Client Platform to get a basic framework to give some guidance. The
Netbeans RCP is pretty good, but it is also complex (like the base Java
libraries). Unfortunately, unlike the base Java libraries, the
Netbeans RCP isn't terribly well documented which can be frustrating.
* Hard to start & stop development. The nature of my work requires
that I switch gears to other disciplines fairly quickly (we're a small
shop). Because of the general complexity of the Java libraries and
Netbeans RCP, I've found it very hard to come back to coding after a
week or two of troubleshooting machinery in the field. It takes me
several days to get back in the swing (no pun intended) of things. I
never had this problem with VB, it was pretty easy to pick up where I
left off. Perhaps this is a language issue, but I think it's more an
issue of the framework. VB was small in comparison to Java. You could
keep the majority of what you needed to know in the back of your head.
Trying to remember how to paint bold text in a JTable in Java sends me
thumbing back through my code to find the various subclasses required.
***Delphi***
Pros:
* Feels familiar. It doesn't seem terribly different than VB6. In
fact, in many ways it's the VB I wished I had (though I didn't know
about it during our version 1.0 development!) It's got a good mix of
procedural programming and OO.
* Good class library with source code. I like that I can see what the
VCL is doing under the hood. VB often had too much black magic.
* Easy GUI builder & tight IDE integration with the language. Some
very convenient and rich visual components.
Cons:
* Proprietary language. I feel a bit burned by the VB6 debacle, and
that makes me gunshy of tieing myself to another single-source
language/tool.
* Documentation isn't so great. The online help is not very helpful.
The books available are good, but few.
* Weird vibe surrounding the company & future development. There's
obviously a lot of history between Borland and the customer base, I'm
not sure what all has happened of the years but there's a tangible
bitterness towards the company.
***.Net***
Pros:
* Possible Interop strategy to gradually port the VB application. I'm
not sure if this is techincally smart, but it certainly sounds nice to
avoid doing the 'big port' all at once.
* Breadth and depth of class library is on par with Java.
* Good documentation.
Cons:
* Winforms is deprecated? I can't find a straight answer on this one,
but it is awfully confusing to hear the yet again the 'next big thing'
from MS is being deprecated. Its confusing to figure out what GUI
toolkit MS is recommending for development today, that has a shelf life
of at least 5 years.
* WPF looks like it has questionable merits. I've seen some demos on
MSDN, I've played with the tools, I've read 1 book, and I'm not sure I
see an advantage to WPF for my work. They appear to be taking the same
course as Swing, custom rendering everything on a base native Canvas
control. This allows for huge flexibilty at the expense of some speed.
With Swing you gain the ability to move across platforms, with WPF you
get locked onto Vista and XPsp2.
* Fool me once, shame on you. Fool me twice shame on me. I'm still a
little aggravated that my VB6 investment is somewhat wasted.
Whew...
At the end of the day, I realize that I *could* get the work done with
any of the above. But, I feel that if I had sought out better advice
when embarking on the initial development during 2001/2002, I never
would have chosen VB6. Therefore, I'm trying to do a better job of
soliciting advice as I head down this same road again (albeit 5 years
later).
If you made it this far along in the message, thank you very much for
your time and attention. Any advice is greatly appreciated.
--
Best regards,
Gareth Conner
Tony Caduto
development with Delphi your other options will pale in
comparison.
I have played with the Netbeans RCP with the forms designer
and while the best Java IDE I have used, it is no where near as
nice as Delphi.
Thanks to Free Pascal, Object Pascal is not really proprietary and you
do have the option of Lazarus.
http://www.freepascal.org
http://www.lazarus.freepascal.org/
The other gem that your other two options are not in the same league is
the plethora of Open Source and free 3rd party components.
Some of My favorites are:
Virtual Tree View:
http://www.delphi-gems.com/VirtualTreeview/
it's the most powerful and flexible tree view I know of.
(also works with Lazarus)
Synapse
http://synapse.ararat.cz/
Probably the best blocking TCP/IP socket library anywhere
(also works with Lazarus)
Synedit
http://synedit.sourceforge.net/
unicode version also available:
http://mh-nexus.de/unisynedit.htm
ICS (Internet Component Suite)
http://www.overbyte.be
Probably the best Async TCP/IP component suite.
Has a incredible FTP server component.
Zeos Database components
Allow full access to Oracle, SQLite,MySQL, PostgreSQL, Firebird etc
http://www.zeoslib.net
There are also many reasonable commercial products available that are
high quality and don't command the ridiculously high prices some third
party Java and .net components do.
You best bet is Delphi.
Tony Caduto
AM Software Design
Home of Lightning Admin
Your best option for Postgresql and MySQL administration tools.
http://www.amsoftwaredesign.com
Dan Barclay
First a little background on myself for calibration. Like you, I'm not
formally trained in computer science. My degree is in Electrical
Engineering, but I created some software and it sort of "took off" so I now
run a software company.
I'm a VB/MS Basic user from way before it was "cool". My first projects
were on CP/M and TRSDOS so I've used pretty much every version of MS Basic,
QuickBasic, Professional Basic, and VB that has existed. I was in the
first group of VB MVP's when they created the MVP program in 1993, and was
in the forefront of those battling to keep Classic VB in play. But, it's
over.
That is, I come from a similar background, I've got a large amount of VB
code, and I know your pain.
I've done a lot of soul searching on the subject of "where to go". It can
depend somewhat on your application and application plans, but in most cases
Delphi appears to be the best target. The more I use it, the more I wish
Basic had been on the Delphi architecture(VCL/IDE). Heck, I *still* wish
they'd make a "DB" (Delphi Basic). But, as you say, Delphi's Object Pascal
feels very nice for a VB guy.
One key difference between the VB debacle and Delphi is that the Delphi
developers *actually use Delphi*. You may or may not be aware, but the guys
responsible for VB simply do not use it. They've *never* used it except for
writing sample code. They are as clueless as to what makes Basic attractive
as anyone on the outside (Borland for example). A huge amount of Delphi
itself is written in Delphi, and it matters. CodeGear *does* understand
Delphi and Delphi users because they are users themselves.
A second key in our decision was that Delphi is designed for the developer
market. VB was not. VB (and the rest of the MS developer tools) are
actually designed to press Microsoft's OS and Office agenda. It is no
accident that MS does not include native development tools, they have a lot
at stake in pressing developers into .Net. They absolutely refused to
include VB6 in current Visual Studio versions even leaving it in its current
form.
Delphi also gives the capability of creating some of your code in a way that
it can be used in both native (Win32) and DotNet without change. When we
first stared looking, you could also use your Delphi code on Linux (still
can, I think, sort of). That takes a bit of thought if you're using library
code, but it can be done. It simply *can't* be done, at all, with C#, VB,
or any other signifcant choice I'm aware of. Since you're doing hardware
interfaces I'm guessing you'll find native code fairly high on your list of
priorities.
Good luck with your decision. I know it's not easy, until you get your feet
well into it. We're quite happy with our decision and I wish I'd started
the move when I first detected the reason to do it in 2001 (ref:
http://vb.mvps.org/tips/stability.asp ). While I've been tinkering with
Delphi during this whole process, we didn't really start serious development
with it (and I didn't start really understanding Delphi) until last year.
Unfortunately, I hung around trying to convince MS to see the light for
several more years. I thought there was hope of success. We were
spectacularly unsuccessful, but we tried.
In starting your move, you need to decide on one of several strategies.
You can do a whole-app conversion. There are conversion tools to help
( www.deluxsoftware.com is of some help but not a complete conversion)
You can create new programs with Delphi, leaving your existing programs
in VB until they die
You can convert in a segmented way, leaving the frontend as VB while you
rewrite logical parts in Delphi (calling them from the VB app).
With the "whole app" conversion you have to shut down app development while
you convert and test. That wasn't reasonable for us, we have to keep our
app moving forward or we're dead. It also presumes you start out knowing
how to program in Delphi, which you won't.
We also didn't want to just create new programs in Delphi. Our primary apps
are in VB and they need to be converted to be viable for the long term. Our
primary assets (code assets) are in a large library, in VB.
So, we're converting in a segmented way. As we get time we convert portions
of our VB library to Delphi and expose those to the existing VB app. At
some point we'll have the VB portion doing nothing but startup and we'll
replace that. This process takes some careful thought, but it can be done.
We've even decided to do it without COM for the calls. That's made it more
of a challenge in some ways, but we're simply tired of the DLL Hell made
worse by COM.
Hope this helps. If you have more questions, ask.
Dan
"Gareth Conner" <garethATcreativeconnersDOTcom> wrote in message
news:45c8...@newsgroups.borland.com...
Shawn B.
> formally trained in computer science. My degree is in Electrical
> Engineering, but I created some software and it sort of "took off" so I
> now run a software company.
>
> I'm a VB/MS Basic user from way before it was "cool". My first projects
> were on CP/M and TRSDOS so I've used pretty much every version of MS
> Basic, QuickBasic, Professional Basic, and VB that has existed. I was in
> the first group of VB MVP's when they created the MVP program in 1993, and
> was in the forefront of those battling to keep Classic VB in play. But,
> it's over.
>
> That is, I come from a similar background, I've got a large amount of VB
> code, and I know your pain.
>
>
A very well written post and insightful.
Thanks,
Shawn
Brian Moelk
> So, from what I've learned throughout my meanderings the tools stack up
> like this:
FWIW, I think your assessment of these tools is quite accurate.
> ***Java (with Netbeans RCP)***
[...]
> Cons:
> * Somewhat convoluted. As a gut reaction, it takes 2x-3x the amount of
> code to get something done compared to VB. I'm sure it's cleaner
> programming, but every task requires a long chain of classes &
> interfaces.
I agree. This is one of the things that has put me off on Java in the
past. What has rekindled my interest is the release of Groovy. For the
cases where Java feels a bit cumbersome, you can mix in some Groovy.
Groovy seamlessly works with Java, as Groovy objects are Java objects.
The IDE/tool support for Groovy is not well developed at all, however it
will only get better and Groovy is pretty easy to use without too much
IDE support. I've played around with some simple UI design with Matisse
to which I've added Groovy event handlers via closures; although it's
more manual than VB/Delphi/Java (right now) it works quite well and
keeps a clean separation between View and Controller.
> ***Delphi***
I love Delphi, and your Pros are spot on; for native Windows GUI's
Delphi owns everything else out there.
But your "Cons" are certainly accurate, especially the "tangible
bitterness part" :) The other Con in comparison to Java is that it's
Windows only; which may or may not be important to you.
Also, just be aware of the natural bias in regards to Delphi since
you're asking on a Delphi forum. :)
> ***.Net***
I think .NET is a good choice too, but I also find that you'll have
close to the same long chaining of classes as Java does (perhaps not as
bad). Also keep in mind this is pretty much a MS only solution. If you
want Mono support, I recommend doing it from day one.
> At the end of the day, I realize that I *could* get the work done with
> any of the above. But, I feel that if I had sought out better advice
> when embarking on the initial development during 2001/2002, I never
> would have chosen VB6. Therefore, I'm trying to do a better job of
> soliciting advice as I head down this same road again (albeit 5 years
> later).
IMO, since you have some time invested in NetBeans and Java, I'd spend
some time playing around with Groovy and see if that might help you
mitigate some of your Cons in regards to Java development. Once you get
used to it, it should give you more concise code and shorten the
start/stop time. I think you'll like it's looser syntax and typing.
It also has something called SwingBuilder, which might aid you in
quickly developing dialogs and simple UIs in code. Like I mentioned
before, hooking up closures to swing widgets might be appealing to you
as well. Anyway, I'm a fan of Groovy, so I suggest you take a quick
look. ;)
> If you made it this far along in the message, thank you very much for
> your time and attention. Any advice is greatly appreciated.
HTH. Welcome to the Delphi community and good luck with your project.
--
Brian Moelk
Brain Endeavor LLC
bmo...@NObrainSPAMendeavorFOR.MEcom
Shawn B.
biased towards Delphi. That said, you're clearly not looking for/concerned
with cross-platform development so Java isn't necessary. Delphi, while I'll
admit, isn't my primary tongue, is actually quite a bit more refined and
very capable of nearly anything you might want to do (except .NET 2.0
interop and .NET 3.0 type stuff).
We tried to "port"/"migrate" a VB6 app (hundreds of thousands of lines of
code) to VB.NET and it wasn't easy. In fact, it isn't even possible without
fixing up by hand roughly 40% of the code and this is "pure" VB6, not a
whole lot of 3rd party dependancies or native win32 calls... just pure
language. So we just rewrite from scratch the parts that matter in C#.
There is the concern of when will Microsoft abandon this platform in favor
of the next. Seems they are very fickle. .NET Remoting now superceded by
WCF, WinForms now superceded by WPF, the previous web application projects
superceded by the web projects (and removing the old web application
projects only to add it back in by Win 2005 SP1). You would get the opinion
that Microsoft doesn't have a direction. That said, .NET is the future (for
Microsoft) and is well supported and has a very large base of users that are
extremely talented and knowledgable.
Delphi, has a very established history and a devout following (though
dwindling from all appearances -- highly anecdotal). The future of Delphi
is no more certain than the future of WinForms. .NET itself won't be
abandoned. Microsoft cannot just leave it and do something else. So its a
relatively sure bet. WinForms really isn't that bad. Probly sufficient for
your needs and I don't get the impression that WinForms will be abandoned at
least during the .NET 3.5 cycle later this year. Besides, WinForms is just
presentation. The backend stuff you'll be doing (TCP and Threading) is well
refined in .NET (I do it daily for work these days and process hundreds of
thousands if not millions of transactions per day doing so).
My advice, unless you truly want to start from scratch and use Delphi,
personally, I would use .NET. It really will be easier to port than going
to Java and Delphi. I will get slammed for saying this in a Delphi
newsgroup but I have my reasons for why I would port to .NET over Delphi: 1)
there are far more people that can do .NET really well than Delphi (in the
United States) -- this is anecdotal belief, mind you, but look at the
jobs... compare the # of .NET jobs to Delphi jobs. Ask people at tech shows
whether they can do Delphi or .NET and count the responses of people who
have even heard of Delphi -- I do it often and encounter far more .NET
developers than people who have heard of Delphi -- in the United States. 2)
I've watched many 3rd party vendors (excellent ones too) leave the Delphi
market and dissappear or switch to the .NET market. 3) Delphi.NET 2.0/3.0
support and 64-bit support and full unicode support is so slow in the coming
that its just too hard for me to take Borland/CodeGear seriously when every
other competitor is absolutely on top of the market and progress; Full
unicode and 64-bit support is so yesterday for nearly everyone else. 4)
there is much more published knowledge solving problems with .NET/Java than
Delphi. 5) In 2 years, Dephi will no doubtedly get this miising support and
make yesterday the new today... but everyone else will already be at next
week. 6) price. Supporting BDS is redicously expensive and for the same
money can get significantly more from an MSDN subscription.
However, the Delphi IDE is top-notch but a good IDE for a sluggishly
progressing langauge is not sufficient in itself for me to ignore the other
platforms that are making *real* progress. If they are up-to-date, I can be
up-to-date. If I limit myself to a language/environment that is slower than
mollasses to get any real new features, than I myself will be not be able to
deliver the said features at a pace even remotely similar to the rest of the
market.
Your needs are special, you don't appear to be dependant upon the market and
current technology, but I believe my reasons for not choosing Delphi would
still apply. Or you can wait a year and see how CodeGear does. If they do
well, I might reconsider my position and you could too (if you didn't
already choose to walk that path).
** I realize this is a matter of opinion. I'm only expressing my own
opinion and do not to intend to present it as fact.
Thanks,
Shawn
Paul Nichols[TeamB]
> Hello folks,
>
>
Gareth,
You have very positive considerations, I would expect on a Delphi NG,
you are going to here USE DELPHI!! Delphi is a great Windows development
tool!
I would suggest that you ask this question on the JBuilder NGs as well.
Just post what your considerations are there as well and see what
responses you get. Compare and see what the results are.
One thing I will say; you mentioned XPlatform. If that is important that
narrows your decision quite a bit.
One more consideration may be deployment. Certain languages/platforms
have built in versioning tools which allow for automatic and seamless
updates.
In other words, your users get your version 1 of the application.
Later, you create a new version, version 2, and put the new app on your
server.
Your user's launch the application, as usual, but when the app starts,
it sees version 2. The new app is automatically downloaded and installed
with no interaction from the user and the new version will be
automatically started in place of the older version from then on. That
is until a new update is put on the server and the process repeats.
Steve Trefethen (Delphi R&D)
news:45c8...@newsgroups.borland.com...
>
> My apologies in advance, this is a somewhat lengthy post...
>
> I've been lurking around these newsgroups for some months and purchased
> a Turbo Delphi Pro license a little while ago. I've had some time to
> play with Delphi, and I'm now mired in a quandry trying to decide my
> best path for continuing development on an existing VB6 application.
Hi Gareth,
Thanks for taking the time to write such a detailed post and welcome to
the newsgroups. From the sound of things you've done a thorough job
exploring your options. Since I work for CodeGear and have worked on the
Delphi team since 1994 I think it's pretty clear where I stand on what tool
you should use. :)
I'll add one comment that people outside of CodeGear can't and that's that I
can't recall as much attention being paid to developer tools here at
Borland/CodeGear since Delphi 3.0 (1997). In fact, I sit next door to Peter
Shambora our Senior Vice President of Worldwide Field Operations, two doors
away from our CFO Cynthia Mignogna and three doors from Ben Smith our CEO.
That may not sound like much unless you consider the fact that until a few
months ago we hadn't had an executive located here in Scott's Valley for
many years.
Btw, I've also attended a few meetings with Lisa Romano our CMO. In years
prior, I'm not sure I would have even recognized the individuals who held
these positions except for Borland's CEO. In fact, Lisa stopped by my office
today while giving a tour to a new PR employee.
Here are some other things I've written about the transition to CodeGear:
http://www.stevetrefethen.com/blog/CategoryView,category,CodeGear.aspx
Lastly, here is a blog post I wrote about moving from VB to Delphi:
or
Good luck with your decision!
-Steve
Delphi R&D
http://www.stevetrefethen.com/blog/
Erwin van den Bosch
<stref...@junk.com> wrote:
>In fact, I sit next door to Peter
>Shambora our Senior Vice President of Worldwide Field Operations, two doors
>away from our CFO Cynthia Mignogna and three doors from Ben Smith our CEO.
>That may not sound like much unless you consider the fact that until a few
>months ago we hadn't had an executive located here in Scott's Valley for
>many years.
Sounds like A small company to me.
Robert Horbry-Smith
> Sounds like A small company to me.
Sounds like a good company to me ...
Rob
--
Peter Morris
> ***Delphi***
> Pros:
> * Feels familiar. It doesn't seem terribly different than VB6. In
> fact, in many ways it's the VB I wished I had (though I didn't know
> about it during our version 1.0 development!) It's got a good mix of
> procedural programming and OO.
>
> * Good class library with source code. I like that I can see what the
> VCL is doing under the hood. VB often had too much black magic.
And you can alter the VCL + recompile it in your app if you need to fix
bugs.
> Cons:
> * Proprietary language. I feel a bit burned by the VB6 debacle
Apparently you can open Delphi 1 source code in Delphi 2006 and it will
compile. Delphi has always had a good record for compatibility, unlike VB
being completely altered.
> * Documentation isn't so great. The online help is not very helpful.
> The books available are good, but few.
Personally I have found that the people in the newsgroups are probably 10
times more helpful than in the MS ones, despite there being a fraction of
the total number of users.
> * Weird vibe surrounding the company & future development. There's
> obviously a lot of history between Borland and the customer base, I'm
> not sure what all has happened of the years but there's a tangible
> bitterness towards the company.
Some people would offer their first born child, yet some people seem to
despise the company and the tool (yet for some odd reason hang around in the
newsgroups). I think though that most people (like myself) sit somewhere in
the middle and just use this great tool for developing fast native Windows
applications in a short amount of time and let the two extremes argue
amongst themselves.
> ***.Net***
> Pros:
> * Possible Interop strategy to gradually port the VB application. I'm
> not sure if this is techincally smart, but it certainly sounds nice to
> avoid doing the 'big port' all at once.
You can do this with Delphi too.
Component menu->Import ActiveX control. Delphi will create a unit with a
strongly typed class wrapping your existing control. You could (if you
wish) slowly port the features over to native Delphi, eventually eliminating
the need for the ActiveX control.
--
Pete
Blessed are the geek, for they shall public class GeekEarth : Earth {}
====
Audio compression components, DIB graphics controls, ECO extensions,
FastStrings
http://www.droopyeyes.com
Erwin van den Bosch
<rhorbry*iinet.net,au> wrote:
>>
>> Sounds like A small company to me.
>
>Sounds like a good company to me ...
A small company can be a good company. But the problem is that if you
build large applications with Delphi you get very dependable of
Codegear. Small companies don't like that. Big companies won't even
consider Delphi.
--
Erwin van den Bosch
Mike B
"Erwin van den Bosch" <er...@tng-applications.nl> wrote in message
news:45c95593....@forums.borland.com...
>
>
> ............................. Big companies won't even
> consider Delphi.
>
How do you know? Do you control what they do?
Mike
Marco Caspers
<snip>
> Sounds like A small company to me.
In fact, what i read from Steve's post is exactly what he wrote, he he
has some executives sitting behind the doors next to him.
Which isn't telling you anything at all from the company other than
perhaps the layout of a single hall in a their office building.
And the good part is, they're all focussed on developers and developing
:).
--
Ray Porter
"Paul Nichols[TeamB]" <pa...@comp.net> wrote in message
news:45c81f93$1...@newsgroups.borland.com...
> Gareth Conner wrote:
> In other words, your users get your version 1 of the application. Later,
> you create a new version, version 2, and put the new app on your server.
>
> Your user's launch the application, as usual, but when the app starts, it
> sees version 2. The new app is automatically downloaded and installed with
> no interaction from the user and the new version will be automatically
> started in place of the older version from then on. That is until a new
> update is put on the server and the process repeats.
>
Paul didn't mention which tools allow this. Java can do it with Java
Jumpstart. Delphi can also do it with tools like TMS Software TWebUpdate
component which works extremely well. That's what we use. I believe
.Net/C# will also allow you to do it with one-click install (someone correct
me if I'm wrong). In any case, it's possible to do this with any of the
tools you've mentioned but some may require more work.
Ray Porter
Ray Porter
Gareth Conner
>
> Virtual Tree View:
> http://www.delphi-gems.com/VirtualTreeview/
> it's the most powerful and flexible tree view I know of.
> (also works with Lazarus)
>
> Synapse
> http://synapse.ararat.cz/
> Probably the best blocking TCP/IP socket library anywhere
> (also works with Lazarus)
>
> ICS (Internet Component Suite)
> http://www.overbyte.be
> Probably the best Async TCP/IP component suite.
> Has a incredible FTP server component.
Thanks for these links, I hadn't heard of them before. The only socket
library I had heard of was Indy (since it's included with Delphi).
I'll certainly take a look at these options
> You best bet is Delphi.
>
Thanks for the response, it's great to hear the enthusiasm!
Gareth Conner
> That is, I come from a similar background, I've got a large amount of
> VB code, and I know your pain.
Thanks Dan, it's always good to hear from a soul who's been down the
same road. To be honest, you are one of my inspirations for taking
such a hard look at Delphi. As I've searched through the newsgroups
via Google, for any topics containing 'VB6' your name comes up
frequently. You obviously understand how the classic VB, warts and
all, could be used as a serious tool and make a viable business with it.
> The more I use
> it, the more I wish Basic had been on the Delphi
> architecture(VCL/IDE). Heck, I still wish they'd make a "DB" (Delphi
> Basic). But, as you say, Delphi's Object Pascal feels very nice for
> a VB guy.
Yep, agreed.
> One key difference between the VB debacle and Delphi is that the
> Delphi developers *actually use Delphi*. You may or may not be
> aware, but the guys responsible for VB simply do not use it. They've
> never used it except for writing sample code. They are as clueless
> as to what makes Basic attractive as anyone on the outside (Borland
> for example). A huge amount of Delphi itself is written in Delphi,
> and it matters. CodeGear does understand Delphi and Delphi users
> because they are users themselves.
Ah, no I didn't realize that the VB team didn't actually use the
language, though it makes the bizarre path to .Net a little clearer.
While it is plain that .Net has some clear technical advantages to
classic VB, completely breaking backwards capability is unforgiveable.
At the end of the day, many of use are not just technologists, but have
businesses to run. From what I've read, this is something that
Delphi/Codegear seems to comprehend. For the most part, it appears
that they have maintained backwards compatability going back a decade
or so (if I'm wrong, I'd appreciate a correction). While it sounds
like Delphi .Net has some technical disadvantages when compared to the
MS tools, it seems laudable that they have extended a bridge to
developers who want to branch some of their code into the .Net world
without totally losing their investment in native code.
> Since you're doing hardware interfaces I'm guessing
> you'll find native code fairly high on your list of priorities.
Yes, it would be nice to have easy access to native code. While many
of our products are driven over TCP sockets (which doesn't need native
code), one of our devices uses USB. I have done the preliminary work
to get that device working in Java, and it isn't much fun. It requires
working with JNI (Java Native Interface), and is a bit of work and
error prone. Not to mention, once you delve into JNI, you start to
lose cross platform capability.
> So, we're converting in a segmented way. As we get time we convert
> portions of our VB library to Delphi and expose those to the existing
> VB app. At some point we'll have the VB portion doing nothing but
> startup and we'll replace that. This process takes some careful
> thought, but it can be done. We've even decided to do it without COM
> for the calls. That's made it more of a challenge in some ways, but
> we're simply tired of the DLL Hell made worse by COM.
This is the path that interests me the most. Part of my fear with the
Java work I've been doing is that because it requires a whole app
conversion. We are already finding bugs that we've introduced in new
areas of the code that had been working fine in VB, but because of the
massive paradigm shift the translation is not clean. *If possible* it
would be great to essentially start refactoring code, class by class,
but in the new language.
I can understand wanting to rid yourself of COM and DLL hell. I'm
curious, how can you manage that? I may be showing some real lack of
understanding, but if you forego COM for plain DLL's you can't pass
objects between your Delphi and VB6 right? Does this mean that your
exposing your new Delphi code as individual function calls? If you
have a moment to expand a little more on your methodolgy, I'd really
love to learn a little more about this.
>
> Hope this helps. If you have more questions, ask.
>
> Dan
>
This was a HUGE help, thank you so much for taking the time to respond
in such a thorough and thoughtful way.
Gareth Conner
> Obviously, asking the question in a Delphi newsgroup will get you
> answers biased towards Delphi. That said, you're clearly not looking
> for/concerned with cross-platform development so Java isn't
> necessary. Delphi, while I'll admit, isn't my primary tongue, is
> actually quite a bit more refined and very capable of nearly anything
> you might want to do (except .NET 2.0 interop and .NET 3.0 type
> stuff).
Yes, I expect there will be a bit of a Delphi bias <g>. However, in
all seriousness, there do seem to be some folks in here that do a fair
amount of both Java & .Net.
Cross-platform is not a requirement. I do have a small fraction of
clients that have been needling me about a Mac OSX version.
Particulary the clients that are universities seem to prefer Mac's.
So, it would be super if I could have something cross-platform without
much effort, but given the relatively small number of requests it may
be cheaper to donate Windows machines to those clients.
> We tried to "port"/"migrate" a VB6 app (hundreds of thousands of
> lines of code) to VB.NET and it wasn't easy. In fact, it isn't even
> possible without fixing up by hand roughly 40% of the code and this
> is "pure" VB6, not a whole lot of 3rd party dependancies or native
> win32 calls... just pure language. So we just rewrite from scratch
> the parts that matter in C#.
Yeah, my experience regarding 'migration' is similar. The current
version doesn't use any 3rd part dependancies, but does have a fair
amount of direct Win32 calls for GDI drawing.
> There is the concern of when will Microsoft abandon this platform in
> favor of the next. Seems they are very fickle. .NET Remoting now
> superceded by WCF, WinForms now superceded by WPF, the previous web
> application projects superceded by the web projects (and removing the
> old web application projects only to add it back in by Win 2005 SP1).
> You would get the opinion that Microsoft doesn't have a direction.
> That said, .NET is the future (for Microsoft) and is well supported
> and has a very large base of users that are extremely talented and
> knowledgable.
It's the fickleness that turns my stomach. A year ago I was cursing
myself for not having originally chosen to develop in VB.Net, v1.0 was
available when I in the early stages of development. But, had I done
that, I would have used Winforms which is now being left to grow moss
it appears.
The only direction that Microsoft seems to be heading is .Net, though
the individual API's seem to flucuate from release to release. One of
the appeals of Java is that it places an insulating layer from the
operating system, so there's always an exit strategy. The other appeal
is that Sun appears to be much more respectful of maintain a stable
API. Changes in Java are slow and well thought out, which I can
appreciate. To be fair, Delphi seems to take pride in having a stable
API as well.
> Delphi, has a very established history and a devout following (though
> dwindling from all appearances -- highly anecdotal). The future of
> Delphi is no more certain than the future of WinForms.
Thanks, that's an interesting point.
> My advice, unless you truly want to start from scratch and use
> Delphi, personally, I would use .NET. It really will be easier to
> port than going to Java and Delphi. I will get slammed for saying
> this in a Delphi newsgroup but I have my reasons for why I would port
> to .NET over Delphi:
I appreciate your honesty, and these are some of the same doubts that
keep spinning in my head. However, I'm a little skeptical about
Microsoft and it's future plans. While .Net will continue on, they
seem to have a fundamental disregard for how much API changes cost
other developers. From what I've read, there were a noticeable number
of breaking changes from .Net versions 1.0, 1.1, & 2.0. Though I hear
that 3.0 is really more of an expansion of the framework.
The massive amount of information that is available for .Net & Java is
a big help when delving into either of those platforms.
> Your needs are special, you don't appear to be dependant upon the
> market and current technology, but I believe my reasons for not
> choosing Delphi would still apply. Or you can wait a year and see
> how CodeGear does. If they do well, I might reconsider my position
> and you could too (if you didn't already choose to walk that path).
Yeah, that's pretty accurate. Most of the technology I need is not
bleeding-edge. Probably waiting another year is not practical for me.
I'm behind on the process as it is, and though we don't have any real
competition at this point in our market, we need to keep our current
customers happy and keep our eyes wide open for other emerging
competitors.
> ** I realize this is a matter of opinion. I'm only expressing my
> own opinion and do not to intend to present it as fact.
>
> Thanks,
> Shawn
Thanks a bunch Shawn, I appreciate your response.
Gareth Conner
> I agree. This is one of the things that has put me off on Java in the
> past. What has rekindled my interest is the release of Groovy. For
> the cases where Java feels a bit cumbersome, you can mix in some
> Groovy. Groovy seamlessly works with Java, as Groovy objects are
> Java objects.
>
> The IDE/tool support for Groovy is not well developed at all, however
> it will only get better and Groovy is pretty easy to use without too
> much IDE support. I've played around with some simple UI design with
> Matisse to which I've added Groovy event handlers via closures;
> although it's more manual than VB/Delphi/Java (right now) it works
> quite well and keeps a clean separation between View and Controller.
That's interesting, I'll have to take a look at Groovy. Does it
complicate distribution much? I suppose it's just another jar file
that has to get stuffed in with your application...
>
> > Delphi
>
> I love Delphi, and your Pros are spot on; for native Windows GUI's
> Delphi owns everything else out there.
>
> But your "Cons" are certainly accurate, especially the "tangible
> bitterness part" :) The other Con in comparison to Java is that it's
> Windows only; which may or may not be important to you.
At present, my app is Windows-only. If I could get cross-platform
capability to OSX without much pain that would be a benefit, but it
isn't a deal-breaker for me.
> Also, just be aware of the natural bias in regards to Delphi since
> you're asking on a Delphi forum. :)
Yeah, I figure I'll have to take the context into considerations :)
> > ***.Net***
>
> I think .NET is a good choice too, but I also find that you'll have
> close to the same long chaining of classes as Java does (perhaps not
> as bad). Also keep in mind this is pretty much a MS only solution.
> If you want Mono support, I recommend doing it from day one.
From the work I've done in .Net, it seems to suffer from much of the
same girth as Java. For lack of a better description, the code gets so
involved that it can kill the fun pretty quickly. The only clear
advantage of .Net over Java that I can see is that it is much easier to
interop with native code.
Mono appears, on the surface, to have the best of both .Net & Java
(easy interop, easy cross-platform). But, the lack of a complete GUI
toolkit on OSX negates the cross-platform benefit, for me.
>
> IMO, since you have some time invested in NetBeans and Java, I'd spend
> some time playing around with Groovy and see if that might help you
> mitigate some of your Cons in regards to Java development. Once you
> get used to it, it should give you more concise code and shorten the
> start/stop time. I think you'll like it's looser syntax and typing.
>
> It also has something called SwingBuilder, which might aid you in
> quickly developing dialogs and simple UIs in code. Like I mentioned
> before, hooking up closures to swing widgets might be appealing to you
> as well. Anyway, I'm a fan of Groovy, so I suggest you take a quick
> look. ;)
I will certainly take a look at Groovy. I've been leveraging the
Netbeans Platform (not just the IDE) as a foundation for the app
because it gives some nice touches for free (docking windows, action
framework, plugin framework, properties grid, etc.). I'm interested to
see how easy it easy to use Groovy within the Netbeans RCP. That could
be a powerful combo.
>
> HTH. Welcome to the Delphi community and good luck with your project.
Thanks Brian, I appreciate your input.
Gareth Conner
> I'll add one comment that people outside of CodeGear can't and that's
> that I can't recall as much attention being paid to developer tools
> here at Borland/CodeGear since Delphi 3.0 (1997).
I think its great that Codegear has a renewed focus on the developer
tools. The re-introduction of the Turbo line is what finally convinced
me to buy a license.
>
> http://www.stevetrefethen.com/blog/CategoryView,category,CodeGear.aspx
>
> Lastly, here is a blog post I wrote about moving from VB to Delphi:
>
> http://www.stevetrefethen.com/blog/ResourcesForConvertingFromMicrosoft
> VisualBasicVBToBorlandsDelphi.aspx
>
> or
>
> http://tinyurl.com/3xwl5b
>
Thanks for the links, those will be handy. I appreciate your response,
it's great to hear from someone at the company.
Brian Moelk
> That's interesting, I'll have to take a look at Groovy. Does it
> complicate distribution much? I suppose it's just another jar file
> that has to get stuffed in with your application...
Yes. From what I've read, it's simply an additional jar file.
> At present, my app is Windows-only. If I could get cross-platform
> capability to OSX without much pain that would be a benefit, but it
> isn't a deal-breaker for me.
From the sounds of what you've described with JNI stuff, there will
probably be some degree of pain involved. I doubt Groovy can help
alleviate the pain there, but, the primary advantage of using Java is
that if you go cross platform, most of the pain will be in that layer.
With windows-only type solutions, you will be faced with difficult
decisions if cross platform becomes important.
> From the work I've done in .Net, it seems to suffer from much of the
> same girth as Java. For lack of a better description, the code gets so
> involved that it can kill the fun pretty quickly. The only clear
> advantage of .Net over Java that I can see is that it is much easier to
> interop with native code.
On the whole I agree; I do think there are some things that .NET does
much better than Java. But Java has been around for quite some time and
the cross platform support is quite good.
> Mono appears, on the surface, to have the best of both .Net & Java
> (easy interop, easy cross-platform). But, the lack of a complete GUI
> toolkit on OSX negates the cross-platform benefit, for me.
IMO, Mono is pretty much a no go for OSX.
> I will certainly take a look at Groovy. I've been leveraging the
> Netbeans Platform (not just the IDE) as a foundation for the app
> because it gives some nice touches for free (docking windows, action
> framework, plugin framework, properties grid, etc.). I'm interested to
> see how easy it easy to use Groovy within the Netbeans RCP. That could
> be a powerful combo.
I think Groovy is a really nice complement for Java; it addresses some
of Java's weaknesses while maintaining its strengths.
Groovy is pretty cutting edge stuff and the tool support is currently
weak. But I do think it's worth a look, especially considering your
existing investment in Java code. OTOH, I can certainly understand if
you choose a different path.
> Thanks Brian, I appreciate your input.
Anytime.
Donald Shimoda
> If you made it this far along in the message, thank you very much for
> your time and attention. Any advice is greatly appreciated.
Gareth Conner wrote:
> If you made it this far along in the message, thank you very much for
> your time and attention. Any advice is greatly appreciated.
After all the another responses, wieth technichal details, i only cant
hope you start with Delphi, you will not be disappointed, guarantee.
HTH
--
Donald.
Gareth Conner
> And you can alter the VCL + recompile it in your app if you need to
> fix bugs.
That is a big advantage over the MS options. I was very happy to see
that I could ctrl+click on a VCL class name in the ide and be brought
right to the source. This is a feature I've learned a good amount from
in Java, and I'm sure it will be just as practical in Delphi. If
nothing else, it helps take the magic out of the framework and gives
some ideas regarding best practices.
> Apparently you can open Delphi 1 source code in Delphi 2006 and it
> will compile. Delphi has always had a good record for compatibility,
> unlike VB being completely altered.
Backwards compatibility is a great benefit. If I had to pick a single
priority, it would be the protection of my investment in coding time.
This is something that both Delphi and Java are clearly better at than
Microsoft's tools.
> Personally I have found that the people in the newsgroups are
> probably 10 times more helpful than in the MS ones, despite there
> being a fraction of the total number of users.
That's good to know. I have to admit I was a little disheartened by
the lack of printed documentation available with Delphi. A good
'Getting Started' tutorial would have been nice. In the end, I found a
combination of books to get me rolling with the basics.
> Some people would offer their first born child, yet some people seem
> to despise the company and the tool (yet for some odd reason hang
> around in the newsgroups). I think though that most people (like
> myself) sit somewhere in the middle and just use this great tool for
> developing fast native Windows applications in a short amount of time
> and let the two extremes argue amongst themselves.
I try not to get religious about tools either, in the end I'll use
whatever offers the most return for the effort. It's just a little
disconcerting to see a bunch of customers that are happy with the
product, but angry with the company that produces the product. When
using a proprietary tool, the health of the company becomes important.
On the flip side, having a proprietary tool does give a clear point of
responsibility for the product. In the world of open source tools,
often times the answer to bugs is, grab the source yourself and fix it.
This can be a double-edged sword...
> You can do this with Delphi too.
>
> Component menu->Import ActiveX control. Delphi will create a unit
> with a strongly typed class wrapping your existing control. You
> could (if you wish) slowly port the features over to native Delphi,
> eventually eliminating the need for the ActiveX control.
I guess I'm more interested in going the other way. Developing new
features in Delphi and exposing them to the existing VB application.
My thought would be to start porting the business logic classes to
Delphi slowly, starting with the threading & socket code (since those
are two of the weaker points in VB). I presume I would do this through
COM, but to be honest, I probably need to do a little more homework on
the mechanics of this.
Thanks for your thoughts.
Dan Barclay
"Gareth Conner" <garethATcreativeconnersDOTcom> wrote in message
news:45c8...@newsgroups.borland.com...
Very carefully<vbg>.
> I may be showing some real lack of
> understanding, but if you forego COM for plain DLL's you can't pass
> objects between your Delphi and VB6 right?
Even using COM, you'll likely restrict yourself to data (though you can use
complex data types). At least that's what we do. A lot of our core library
is in the form of flat subs and functions (at least at the top level).
Those functions may do something complex (form or object based operations)
but the call itself is wrapped in a simple function.
> Does this mean that your
> exposing your new Delphi code as individual function calls? If you
> have a moment to expand a little more on your methodolgy, I'd really
> love to learn a little more about this.
Without going into too much detail, we've developed a library for
marshalling complex data between VB and Delphi using straight DLL calls. It
was some extra work to write and debug, but it completely eliminates worries
about COM. It's also under our complete control, so if we need something we
can put it in. It puts that marshalling in bitstream form so we can use it
across any buffered or streaming interface (not restricted to DLL calls).
DotNet and SOAP let you do that, but we don't have to have those in the
loop. Our solution is restricted to our own needs so it's probably not
generic enough for general distribution, but it works for us and we have
long term plans for the design. We handle native types, complex types
(UDT/records), arrays, and arrays of those.
FWIW, I would recommend for most conversions that you keep the conversion
itself as simple as possible. Unfortunately, that means you should use COM
or simple dll calls unless you have a long term use for the marshaling code.
> This was a HUGE help, thank you so much for taking the time to respond
> in such a thorough and thoughtful way.
You're welcome.
Dan
Gareth Conner
> > I can understand wanting to rid yourself of COM and DLL hell. I'm
> > curious, how can you manage that?
>
> Very carefully<vbg>.
LOL, yeah I bet!
> FWIW, I would recommend for most conversions that you keep the
> conversion itself as simple as possible. Unfortunately, that means
> you should use COM or simple dll calls unless you have a long term
> use for the marshaling code.
>
OK, I think I should do a little more research on the specifics of
sharing libraries between VB & Delphi to discover what options would
best suit my current code structure.
Thanks again.
Dan Barclay
"Gareth Conner" <garethATcreativeconnersDOTcom> wrote in message
To give you a starting point:
Straight DLL calls using any VB declaration works. Consider your VB
declaration first since VB rules are more restrictive (Delphi has more
flexibility than VB on that). I'd personally stick with simple numeric
variables and character buffers (byte arrays/strings on the VB side to pChar
on the Delphi side). Numerics pass directly, given the declarations.
Buffer lengths don't pass, and you want to be sure you don't write outside
the buffer on return. If you try to pass UDT's to Records, stick with
numeric fields only and be prepared for issues with alignment.
Using COM lets you lace up more complex types and reduce worry about
buffer lengths and such. It's not a bad solution except that, well, it's
COM. If you're using VB you've got a ton of that anyway<g>. I'm sure you
know that with Delphi you can link your entire app (components and all) into
a single EXE. I live for the day I can shed the VB COM part.<sigh>
Technically you can callback into your VB code. IMHO life is too short
for that unless you *really* need it. So far I've avoided it, keeping the
VB code as the startup and caller.
Others here can help you build COM with Delphi. I don't have much
experience with that and I'm trying my best not to learn it<g>. I think
it's easy, but I don't really want to know!
Dan
Thomas Mueller
Tony Caduto wrote:
> The other gem that your other two options are not in the same league is
> the plethora of Open Source and free 3rd party components.
I think you underestimate what's available for Java and .NET.
MfG
twm
Rick Carter
>Others here can help you build COM with Delphi. I don't have much
>experience with that and I'm trying my best not to learn it<g>. I think
>it's easy, but I don't really want to know!
Lino Tandros had a great quote on this. He said something like "COM is
like smoking. If you haven't started, don't start. If you have, stop."
:-)
Rick Carter
cart...@despammed.com
Chair, Delphi/Paradox SIG, Cincinnati PC Users Group
--- posted by geoForum on http://delphi.newswhat.com
Thomas Mueller
"Gareth Conner" <garethATcreativeconnersDOTcom> wrote:
> That's good to know. I have to admit I was a little disheartened by
> the lack of printed documentation available with Delphi. A good
> 'Getting Started' tutorial would have been nice. In the end, I found a
> combination of books to get me rolling with the basics.
There is a lot of good tutorials in the net. In the Delphi Wiki at
http://delphi.wikia.com we try to collect usefull information and links
regarding Delphi. There is also a section on books which might be
interesting for you http://delphi.wikia.com/wiki/Books
I can't really offer you any advice for you original question because I am
strongly biased towards Delphi. I have developed with VB6 for several years
after working for a Delphi shop, also for several years. I have quit that
job and will now move on, to a Delphi shop again, starting on Tuesday next
week. I really look forward to not seeing any VB code again, ever.
MfG
twm
Dan Barclay
news:45c8ca60$1...@newsgroups.borland.com...
> Dan Barclay wrote:
>>Others here can help you build COM with Delphi. I don't have much
>>experience with that and I'm trying my best not to learn it<g>. I think
>>it's easy, but I don't really want to know!
>
> Lino Tandros had a great quote on this. He said something like "COM is
> like smoking. If you haven't started, don't start. If you have, stop."
> :-)
I can relate to that. I do consume external COM interfaces, but they're 3rd
party and that's the way it is.
I also neglected to mention an option to Gareth that is a reasonable
(temporary) option. I've been practicing the process of converting from the
bottom up. It's not unreasonable to create COM dll's with VB and converting
from the top down. I've avoided that so far, but it's certainly reasonable.
Dan
Gareth Conner
> There is a lot of good tutorials in the net. In the Delphi Wiki at
> http://delphi.wikia.com we try to collect usefull information and
> links regarding Delphi. There is also a section on books which might
> be interesting for you http://delphi.wikia.com/wiki/Books
>
Thanks Thomas, I have found the wiki site to be useful over the past
weeks. In the end, I found that Inside Delphi 2006 was a great
introductory book, and Cantu's Mastering Delphi 2005 has been for good
for getting a peek at some of the more advanced topics. Finally,
Delphi in a Nutshell seems to have a nice concise overview of the
language.
Good luck in your new job!
Gareth Conner
> Using COM lets you lace up more complex types and reduce worry about
> buffer lengths and such. It's not a bad solution except that, well,
> it's COM. If you're using VB you've got a ton of that anyway<g>.
> I'm sure you know that with Delphi you can link your entire app
> (components and all) into a single EXE. I live for the day I can
> shed the VB COM part.<sigh>
Yes, I too look forward to the day that I can ship a single EXE.
Currently, my VB app consists of the main project, several COM DLL's,
and one ActiveX EXE server (to provide the multithreading support,
which in VB had to be an out-of-process server). The low hanging fruit
*seems* like it would be the DLL's and ActiveX exe. Since those chunks
are pretty well isolated currently, they may be a good place to start
porting.
I'm no fan of COM, since it was a source of distribution headaches for
me, but it may be the quickest route for now...
> Others here can help you build COM with Delphi. I don't have much
> experience with that and I'm trying my best not to learn it<g>. I
> think it's easy, but I don't really want to know!
>
> Dan
If I end up pursuing this route, and get stuck, I'll post the more
technical questions in one of the other newsgroups. Thanks again for
sharing your experience Dan.
Craig
> development with Delphi your other options will pale in
> comparison.
>
Especially when doing Compact Framework, WPF or WCF development. Then
Delphi really rocks!
Herbert Sitz
> Peter Morris wrote:
> > Personally I have found that the people in the newsgroups are
> > probably 10 times more helpful than in the MS ones, despite there
> > being a fraction of the total number of users.
>
> That's good to know. I have to admit I was a little disheartened by
> the lack of printed documentation available with Delphi. A good
> 'Getting Started' tutorial would have been nice. In the end, I found a
> combination of books to get me rolling with the basics.
>
I would agree with Peter that Delphi newsgroups have a critical mass and are
faster and easier to get good answers in than, e.g., MS newsgroups.
Regarding documentation, the Language Reference that came with Delphi 7 is a
little work of art, great reference. Not good on the how-to's, but
excellent to look up how the language works. Also, "Delphi in a Nutshell"
book is excellent reference as well as Delphi Basics:
http://www.delphibasics.co.uk/
There are only so many books that can be helpful. Other tools may have
more, but a lot of them are repeats.
For third party Delphi tools, libraries, frameworks, there are not really
any books, but generally the third-party newsgroups are very helpful with
interaction directly with the guys that wrote the code.
-- Herb Sitz
Herbert Sitz
news:45c89e1f$1...@newsgroups.borland.com...
>
> I think Groovy is a really nice complement for Java; it addresses some
> of Java's weaknesses while maintaining its strengths.
>
> Groovy is pretty cutting edge stuff and the tool support is currently
> weak. But I do think it's worth a look, especially considering your
> existing investment in Java code. OTOH, I can certainly understand if
> you choose a different path.
>
> Brian Moelk
> Brain Endeavor LLC
> bmo...@NObrainSPAMendeavorFOR.MEcom
Brian -- FYI, I was curious to read this article in SDTimes a little while
ago:
"Groovy: Alive, but Barely Kicking",
http://www.sdtimes.com/printArticle/story-20070115-04.html
-- Herb Sitz
Brian Moelk
> Brian -- FYI, I was curious to read this article in SDTimes a little while
> ago:
>
> "Groovy: Alive, but Barely Kicking",
> http://www.sdtimes.com/printArticle/story-20070115-04.html
Interesting. The thing that I really like about Groovy on top of the
JVM is its integration with Java. It is Java. There is no "bridge" or
"compatibility layer" of any kind. This isn't a big deal, but besides
other than Java, it's the only language to be JSR'd for the JVM.
If JRuby/Jython "succeeds" where Groovy "fails", I'd be just as happy
with that. I'd probably end up choosing to use JRuby.
Dan Barclay
DelphiBasics install. It's only a few bucks and I keep it up most of the
time I'm using Delphi. Maybe one day they'll get the Delphi Help as good as
DelphiBasics, but it's not there now.
I also strongly recommend getting Cantu's "Mastering Delphi xxxx" (whatever
is the latest). Read it from cover to cover. You won't remember
everything, but it'll flood you with the concepts. When you need specifics
you'll remember that it's in there somewhere and can go back and get it.
Help/DelphiBasics is like looking through a soda straw or magnifying glass
(which you need). Cantu's book lets you see from higher up. A new
developer needs both.
Dan
"Herbert Sitz" <hs...@nwlink.com> wrote in message
news:45c902e0$1...@newsgroups.borland.com...
Ingvar Nilsen
> My apologies in advance, this is a somewhat lengthy post...
Hi Gareth! I started reading your post, and could not stop, it is such
an interesting read and you have such a good overview and insight in
both what you want to achieve, and in what tools are out there for you
to use.
Myself I have been using Delphi i since 1995, I have been with several
companies, and the Delphi applications I have written have mostly been
business to business software, now being used all over the world.
Since 2002 I also have used C# and .Net, especially ASP.Net. I really
like .Net, and love C# as much as Delphi, if not more. I have very
little negative to say about .Net, and the Visual Studio IDE is a very
good workplace.
So - I know two worlds, Delphi and .Net, have never programmed in Java
at all, never in VB. Now, what advice can I give? I am trying to put
myself in your position, the software you want to make, and the use of
the software, very interesting software BTW, I am excited about
anything that tastes automation, controlling external motors etc. :)
I think choosing between these two, you have almost given the answer:
> ***Delphi***
> Pros:
> * Feels familiar. It doesn't seem terribly different than VB6.
Delphi has a strong community, you will find any 3rd party component or
library you can imagine plus a whole bunch more, and you most likely
will be up and running very soon. The more you use Delphi, the more you
will discover that is has practically no limitations at all.
It is way more versatile and powerful than its reputation, which BTW
always has been good.
I recently started using a DAW (recording digital music) and was
positively surprised how may applications and VST-plugins (filters) are
written in Delphi. The reason for this may vary, but I suspect they
choose Delphi for its power and direct communication with the Windows
API. A couple of milliseconds faster execution may mean make or break
for this kind of software.
Now, back to your needs. Delphi also used to be the perfect match for
these kind of applications, and I believe it still is. You can't go
wrong IMO.
Good luck!
--
Ingvar Nilsen
Brand New Web Site! Free Delphi Tool:
http://www.ingvarius.com
Brad White
That does put it in a different light, doesn't it.
--
Thanks,
Brad.
Bob
Please do not use sarcasm.
Steve Thackery
You are familiar with it, the product is already written in it, so why
change it?
Forget about Microsoft "no longer supporting" VB6. Remember, VB6 is just
another application running on W32, and Microsoft has pledged to continue
W32 in Vista and all subsequent operating systems "for the foreseeable
future". (You can find that in the MSDN area somewhere, can't remember
exactly where just now).
The thing is, your VB6 development environment isn't suddenly going to stop
working. Neither will your applications written in VB6.
For instance, we've still got die-hards in this newsgroup coding W32 apps in
Delphi 5, and there is no reason at all why they can't continue doing that
indefinitely.
It is completely normal for organisations to keep ancient development
environments up and running in order to maintain ancient but perfectly
serviceable applications. My employer is still using a VAX and a 25 year
old compiler to maintain the code on one of its products (a PABX).
I think you need to examine your reasons for changing. Only if you are sure
you need to, should you make that leap.
Remember, there is only one reason to use .NET: it improves developer
productivity. There is nothing you can do in .NET that you can't do in
Delphi or VB6. Is developer productivity important here? If so, you should
seriously consider it. Also, it is probably the one environment which
stands half a chance of porting your existing code. OK, it's real tough,
but to go anywhere else you'll have to ditch your code and start again.
Java brings nothing to the game that .NET doesn't already do, and usually
better, apart from cross-platform. You've said that isn't important, so
forget it. Cross-platform also means crummy-looking user interfaces (the
lowest common denominator effect).
Delphi is the best W32 development environment by far. But in my opinion
there is no point at all in you moving to it. Again, it brings nothing to
the party that you can't do already, and it's a different language, so it
means ditching your old code.
Honestly, if you can, don't change. If you feel you must, the only logical
choice is VB .NET.
Thack
Paul Nichols[TeamB]
> "Paul Nichols[TeamB]" <pa...@comp.net> wrote in message
> news:45c81f93$1...@newsgroups.borland.com...
>> Gareth Conner wrote:
>> In other words, your users get your version 1 of the application. Later,
>> you create a new version, version 2, and put the new app on your server.
>>
>> Your user's launch the application, as usual, but when the app starts, it
>> sees version 2. The new app is automatically downloaded and installed with
>> no interaction from the user and the new version will be automatically
>> started in place of the older version from then on. That is until a new
>> update is put on the server and the process repeats.
>>
>
> Paul didn't mention which tools allow this. Java can do it with Java
> Jumpstart.
Java Jumpstart?
>
Gareth Conner
> I'm going to rock the boat here, and suggest you stay with VB6!
>
> You are familiar with it, the product is already written in it, so
> why change it?
I don't mind maintaining the existing code in VB6. However, the next
release has some substantial additions that would greatly benefit from
some of the OO niceties of most other languages. In particular,
working without inheritance leads to a lot of repetitive coding & silly
copy/paste bugs.
But, I appreciate the sentiment! I had started refactoring some of the
code in VB6 to prep for the new features, but gave up when the amount
of work started to become obviously large. The fact of the matter is
that eventually the code will need to be ported just to keep it on a
supported platform. And the longer I keep developing new code in VB6,
the harder the porting process is going to be.
> It is completely normal for organisations to keep ancient development
> environments up and running in order to maintain ancient but
> perfectly serviceable applications. My employer is still using a VAX
> and a 25 year old compiler to maintain the code on one of its
> products (a PABX).
Yeah, though my problem is not just keeping legacy code in our company,
but selling it to new customers with varying hardware. Though, I am
happy to see that our current program runs OK on Vista...
>
> Honestly, if you can, don't change. If you feel you must, the only
> logical choice is VB .NET.
>
> Thack
Thanks Steve, I appreciate the input.
Gareth Conner
> Now, what advice can I give? I am trying to put
> myself in your position, the software you want to make, and the use of
> the software, very interesting software BTW, I am excited about
> anything that tastes automation, controlling external motors etc. :)
Thanks Ingvar! I find it exciting too :)
If your interested, there's a quicktime movie of some lifts &
turntables being driven by the software during a shop setup:
http://www.creativeconners.com/statefarm_demo_movie.htm
this is a lengthier movie that shows some of the software with a
motorized training model (that fits on a table top).
http://www.creativeconners.com/prod_demo_movie.htm
> Delphi has a strong community, you will find any 3rd party component
> or library you can imagine plus a whole bunch more, and you most
> likely will be up and running very soon. The more you use Delphi, the
> more you will discover that is has practically no limitations at all.
> It is way more versatile and powerful than its reputation, which BTW
> always has been good.
In the short time that I've been experimenting with Delphi I have been
impressed with how quickly I can get things working. Generally, there
are fewer steps to achieve a desired result than the other platforms.
Since you mentioned that you enjoy working with C#/.Net these days,
perhaps even more than Delphi, could you point to a couple of your
favorite advantages?
> Now, back to your needs. Delphi also used to be the perfect match for
> these kind of applications, and I believe it still is. You can't go
> wrong IMO.
> Good luck!
Thanks for the response! I'm going to try and dig a little deeper into
Delphi this week and try my hand at getting the some of the sockets &
threading stuff working to get a more complete feel for it all.
Gareth Conner
> >
> > Paul didn't mention which tools allow this. Java can do it with
> > Java Jumpstart.
>
> Java Jumpstart?
>
I presume Ray meant Java Webstart, but Jumpstart brings a more humorous
image to mind :)
Ray Porter
"Gareth Conner" <garethATcreativeconnersDOTcom> wrote in message
> Paul Nichols[TeamB] wrote:
>
>
>> >
>> > Paul didn't mention which tools allow this. Java can do it with
>> > Java Jumpstart.
>>
>> Java Jumpstart?
>>
>
> I presume Ray meant Java Webstart, but Jumpstart brings a more humorous
> image to mind :)
Yes, Webstart is what I meant. Sorry -- too many neurons firing out of
sequence as I get closer to retirement age. <grin>
Ray
Ingvar Nilsen
> If your interested, there's a quicktime movie of some lifts
I will have a look tomorrow, too late now..
BTW, had a look at your web site, it is the first time I have seen a
real physical "Show Stopper", so far it has only been an expression to
me :-))
> Since you mentioned that you enjoy working with C#/.Net these days,
> perhaps even more than Delphi, could you point to a couple of your
> favorite advantages?
This requires a long post, but here is the short-form:
The C# language is a "new" language, 6-8 years old I assume. In the
.Net environment everything is an object, also "loose" integers, you
can for example type 3.ToString() which gives you "3".
Types in .Net typically have built-in functions where you in Delphi
sometimes must use separate functions from a library. This means that
in a modern IDE with code completion, intelli-sense and all that kind
of stuff, there is less to memorise because most functions you need are
there at hand when pressing Ctrl + Space. IOW, productivity and speed.
The main reason I use .Net however, is ASP.Net. And the main reason I
use Visual Studio is ASP.Net 2.0. After many years of Internet and Web
and HTML and Javascript etc., in my opinion it was first with ASP.Net
2.0 and Visual Studio we saw the first real RAD production environment
for making web sites.
People are different, I on my side want to program a web site, like any
other application, I do not like scripting. This I can do in ASP.Net
2.0. We are all waiting for the next version of Delphi which will
support .Net 2.0, to be able to achieve the same and perhaps more in
Delphi.
Now, back to Delphi and the language also called Delphi. I know a
little assembler, you can write assembler in Delphi using the built in
assembler, BASM. In fact, I love it, but I am not anywhere near the
real BASM experts in skills. After learning this, I also understand
better what Delphi does when compiling its Delphi Pascal code. Delphi
is much closer to the metal as I see it, and I would prefer it for all
kinds of applications that have anything to do with controlling
hardware.
So, I prefer .Net for business logic and Delphi when I want to get my
feet wet and my hands dirty. .Net is for those putting enamel on a car,
Delphi for those who overhaul the gearbox, if you understand :)
This is my perspective, others certainly have quite different views.
> Thanks for the response! I'm going to try and dig a little deeper
> into Delphi this week and try my hand at getting the some of the
> sockets & threading stuff working to get a more complete feel for it
> all.
Have a look at my site - written in ASP.Net 2.0, marketing a free
Delphi tool <g>
Steve Trefethen (Delphi R&D)
> A small company can be a good company. But the problem is that if you
> build large applications with Delphi you get very dependable of
> Codegear. Small companies don't like that. Big companies won't even
> consider Delphi.
To name two, Yahoo and Skype use Delphi and their not what I consider small.
http://www.stevetrefethen.com/blog/YahooGoForTVYeahItsWrittenInDelphi.aspx
http://www.stevetrefethen.com/blog/SkypeYeahItTooIsWrittenInDelphi.aspx
For a larger list I'm sure DavidI could help.
--
-Steve
Delphi/Delphi.NET/C#Builder R&D
CodeGear
http://www.stevetrefethen.com/blog
Herbert Sitz
> Herbert Sitz wrote:
> > Brian -- FYI, I was curious to read this article in SDTimes a little
while
> > ago:
> >
> > "Groovy: Alive, but Barely Kicking",
> > http://www.sdtimes.com/printArticle/story-20070115-04.html
>
> Interesting. The thing that I really like about Groovy on top of the
> JVM is its integration with Java. It is Java. There is no "bridge" or
> "compatibility layer" of any kind. This isn't a big deal, but besides
> other than Java, it's the only language to be JSR'd for the JVM.
>
That was my understanding, that Groovy had much higher degree of integration
with Java than JRuby or Jython. Or complete integration versus merely
running separately on the JVM. That's why I was surprised to read that
article. Maybe Sun plans to provide same sort of integration for JRuby now
that they're running the JRuby project.
-- Herb
Jolyon Smith
> Remember, VB6 is just
> another application running on W32, and Microsoft has pledged to continue
> W32 in Vista and all subsequent operating systems "for the foreseeable
> future". (You can find that in the MSDN area somewhere, can't remember
> exactly where just now).
> For instance, we've still got die-hards in this newsgroup coding W32 apps in
> Delphi 5, and there is no reason at all why they can't continue doing that
> indefinitely.
Not so long ago the same might have been said about die-hards using
Delphi 1 to write W16 apps. But things change: aiui W16 is not
supported by Vista. No way, no how.
The annoying thing about time is it's relentless nature.
Eventually the "foreseeable" future becomes the knowable. Then, before
you know it, it's _history_.
:)
--
Jolyon Smith
Say, do any of you guys know how to Madison?
Dan Barclay
> I'm going to rock the boat here, and suggest you stay with VB6!
That's reasonable advice, but for a limited number of apps.
> Forget about Microsoft "no longer supporting" VB6. Remember, VB6 is just
> another application running on W32, and Microsoft has pledged to continue
There's a slight difference when it comes to VB.
MS has said that VB apps will continue to run, but they're talking about
*pure* VB apps and the VB runtime. There simply aren't many of those, at
least not with large apps. Most use external components of one sort or
another and those vendors are long gone. Poof. Adios. Unlike the Delphi
world, few of those provided source even if you paid extra, and that source
was generally C++ using yet another set of libs. The infrastructure is on
its death bed for real apps.
IMHO that's what will break VB apps... and MS will claim clean hands.
Apps that have a fairly well defined lifetime (2 to 5 years of usefulness)
you can leave alone.
Apps that you expect to have a long life ("new legacy"), will eventually
have to be moved off VB. That also goes for apps that contain *code
libraries* that you want to use in future apps. Excepting life limited
code, it's wise to start moving before you "have to".
Dan
"Steve Thackery" <th...@nowhere.net> wrote in message
news:45c9...@newsgroups.borland.com...
Brian Moelk
> "Groovy: Alive, but Barely Kicking",
> http://www.sdtimes.com/printArticle/story-20070115-04.html
I find it very interesting to hear Monson Haefel take that stand now.
Before he was a huge advocate of Groovy and worked in the whole JSR process:
http://rmh.blogs.com/weblog/2006/02/groovy_the_slee.html
http://webservices.sys-con.com/read/44117.htm
"It's my opinion, and I believe
the opinion of those who support this JSR, that Groovy is the best
choice because it was built from the ground up for the Java Platform and
uses syntax that is familiar to Java developers, while leveraging some
of best features that Python, Ruby and Smalltalk have to offer."
"Jython and JRuby are excellent examples of how existing languages can
be ported to the Java platform," he continues, "but they are, after all,
ports. They use syntax that is not designed with Java developers in mind
and they are founded on a completely different set of code libraries.
Groovy is designed for Java developers and its foundation is the
standard APIs of the Java Platform."
I wonder what made him grow so sour on Groovy? Just a year ago, he was
a strong advocate for Groovy. I haven't seen mention of anything from
within the Groovy community about his recent change of heart. *shrug*
Brian Moelk
> That was my understanding, that Groovy had much higher degree of integration
> with Java than JRuby or Jython. Or complete integration versus merely
> running separately on the JVM.
Yes, that's what I understand to be the case.
> That's why I was surprised to read that
> article.
It is indeed very strange remarks from a guy that claims his "proudest
achievement was instigating JSR-241, The Groovy Language Specification."
(http://www.monson-haefel.com/work.html)
> Maybe Sun plans to provide same sort of integration for JRuby now
> that they're running the JRuby project.
I'm not sure. I really like Ruby too, so if JRuby works well on the
JVM, I'd be happy to use it.
Shawn B.
> language, though it makes the bizarre path to .Net a little clearer.
> While it is plain that .Net has some clear technical advantages to
> classic VB, completely breaking backwards capability is unforgiveable.
A bit off-topic, but I have heard from multiple places (though I can't
recall which) that the VB.NET team wasn't actually composed of the VB6 team
and that has a lot to do with the breaking changes in the language, though I
don't know how to confirm that "rumour".
Thanks,
Shawn
Dan Barclay
"Shawn B." <lea...@html.com> wrote in message
news:45c9...@newsgroups.borland.com...
I can tell you that is the case. A few people were holdovers, but the core
management team and, more importantly, those in charge of the language were
all changed. One of the PM's was there from VB6 (on the team in some
capacity since VB4), but he had very little VB experience himself. Worse,
he had (has) individuals on his team with even less experience that seem to
run the show.
FWIW, the initial design parameters they set down for VB7 (VB.Net) were
great. They just didn't follow them. In particular, they abandoned the
core "Statement of Principles" in that document. Refer to
http://vb.mvps.org/vfred/langspec.asp
They ended up with a bunch of langauge zealots who decided, without
understanding the language or user base, to "clean up the language".
Dan
Ingvar Nilsen
> Erwin van den Bosch wrote:
> > A small company can be a good company. But the problem is that if
> > you build large applications with Delphi you get very dependable of
> > Codegear. Small companies don't like that. Big companies won't even
> > consider Delphi.
>
> To name two, Yahoo and Skype use Delphi and their not what I consider
> small.
Well, Skype probably was not big when "considering Delphi", but we of
course believe they *got* big *because* of Delphi
Ray A.
> Hello folks,
>
> My apologies in advance, this is a somewhat lengthy post...
>
> I've been lurking around these newsgroups for some months and
> purchased a Turbo Delphi Pro license a little while ago. I've had
> some time to play with Delphi, and I'm now mired in a quandry trying
> to decide my best path for continuing development on an existing VB6
> application.
>
> I am not what you would consider a professional programmer, since I
> lack any formal training (other than a couple of comp sci classes I
> took while earning my degree in theatre!). However, the company I run
> makes its business by developing and selling Ethernet-enabled motor
> control devices and control software for use in live entertainment
> (musical performances, etc.). We split our time between developing
> electronic gadgets, firmware, machinery, and desktop software.
>
> Our main desktop software was originally developed in VB6, and has
> served us pretty well for the past several years. However, we are
> faced with updating the software for the next major version and I'm
> trying to make the most prudent decision regarding which platform to
> use. This is a process I've been looking at casually for well over a
> year, and has been back-burnered a number of times as more pressing
> needs required attention. I've been seriously considering: Java with
> the Netbeans RCP, Delphi, and VB/C# .Net.
>
> Over a couple of months of sporadic work, I've gotten about 20% into a
> Java port leveraging the Netbeans RCP. Though I'm somewhat pleased
> with the result, I'm still plagued with enough doubt to lead me in a
> vicious circle of constantly evaluting other platforms. As I've read
> posts from other folks in this newsgroup, it's apparent that many
> people here are well experienced in all of the same platforms I'm
> considering. I'm hoping to hear some words of wisdom to help me put
> my doubts to an end and forge forward with development on the best
> path.
>
> The application requirements can be met by any of the tools in
> question. It controls a network of motors via TCP sockets. There is
> a fair amount of background processing happening all the time, so the
> app must be multi-threaded (currently implemented as an ActiveX COM
> server in VB version). The main GUI isn't flashy, but has a tree
> view, grid view, and a 2d real-time schematic that depicts the
> scenery as it moves around on stage.
>
> So, from what I've learned throughout my meanderings the tools stack
> up like this:
>
> ***Java (with Netbeans RCP)***
> Pros:
> * Extremely well documented. Easy to find answers to questions.
>
> * Vast class library. Many times things you want to do, are already
> implemented (if you can find them).
>
> * Swing is a very flexible & powerful GUI toolkit with a well-designed
> API.
>
> * Cross platform.
>
> * Garbage collection relieves some responsibility.
>
> * Easy sockets & multi-threading.
>
> Cons:
> * Somewhat convoluted. As a gut reaction, it takes 2x-3x the amount
> of code to get something done compared to VB. I'm sure it's cleaner
> programming, but every task requires a long chain of classes &
> interfaces.
>
> * Swing is almost too flexible. I've been using the Netbeans Rich
> Client Platform to get a basic framework to give some guidance. The
> Netbeans RCP is pretty good, but it is also complex (like the base
> Java libraries). Unfortunately, unlike the base Java libraries, the
> Netbeans RCP isn't terribly well documented which can be frustrating.
>
> * Hard to start & stop development. The nature of my work requires
> that I switch gears to other disciplines fairly quickly (we're a small
> shop). Because of the general complexity of the Java libraries and
> Netbeans RCP, I've found it very hard to come back to coding after a
> week or two of troubleshooting machinery in the field. It takes me
> several days to get back in the swing (no pun intended) of things. I
> never had this problem with VB, it was pretty easy to pick up where I
> left off. Perhaps this is a language issue, but I think it's more an
> issue of the framework. VB was small in comparison to Java. You
> could keep the majority of what you needed to know in the back of
> your head. Trying to remember how to paint bold text in a JTable in
> Java sends me thumbing back through my code to find the various
> subclasses required.
>
> ***Delphi***
> Pros:
> * Feels familiar. It doesn't seem terribly different than VB6. In
> fact, in many ways it's the VB I wished I had (though I didn't know
> about it during our version 1.0 development!) It's got a good mix of
> procedural programming and OO.
>
> * Good class library with source code. I like that I can see what the
> VCL is doing under the hood. VB often had too much black magic.
>
> * Easy GUI builder & tight IDE integration with the language. Some
> very convenient and rich visual components.
>
> Cons:
> * Proprietary language. I feel a bit burned by the VB6 debacle, and
> that makes me gunshy of tieing myself to another single-source
> language/tool.
>
> * Documentation isn't so great. The online help is not very helpful.
> The books available are good, but few.
>
> * Weird vibe surrounding the company & future development. There's
> obviously a lot of history between Borland and the customer base, I'm
> not sure what all has happened of the years but there's a tangible
> bitterness towards the company.
>
> ***.Net***
> Pros:
> * Possible Interop strategy to gradually port the VB application. I'm
> not sure if this is techincally smart, but it certainly sounds nice to
> avoid doing the 'big port' all at once.
>
> * Breadth and depth of class library is on par with Java.
>
> * Good documentation.
>
> Cons:
> * Winforms is deprecated? I can't find a straight answer on this one,
> but it is awfully confusing to hear the yet again the 'next big thing'
> from MS is being deprecated. Its confusing to figure out what GUI
> toolkit MS is recommending for development today, that has a shelf
> life of at least 5 years.
>
> * WPF looks like it has questionable merits. I've seen some demos on
> MSDN, I've played with the tools, I've read 1 book, and I'm not sure I
> see an advantage to WPF for my work. They appear to be taking the
> same course as Swing, custom rendering everything on a base native
> Canvas control. This allows for huge flexibilty at the expense of
> some speed. With Swing you gain the ability to move across
> platforms, with WPF you get locked onto Vista and XPsp2.
>
> * Fool me once, shame on you. Fool me twice shame on me. I'm still a
> little aggravated that my VB6 investment is somewhat wasted.
>
> Whew...
>
> At the end of the day, I realize that I could get the work done with
> any of the above. But, I feel that if I had sought out better advice
> when embarking on the initial development during 2001/2002, I never
> would have chosen VB6. Therefore, I'm trying to do a better job of
> soliciting advice as I head down this same road again (albeit 5 years
> later).
>
> If you made it this far along in the message, thank you very much for
> your time and attention. Any advice is greatly appreciated.
Hello Gareth,
I used to be a VB6 programmer about 7 years ago and I have to say
switching to Delphi was a good decision.
If you are motivated to produce you don't have to be an expert to make
big accomplishments building applications in Delphi. Eventually you
will pick up and gain confidence in a lot of things if you have the
desire to understand why something works or why something does not.
Google helps a lot too. Looking back I've really learned many things
using Delphi and built better software because of it.
My boss asked me one day if he made the right decision going with
Delphi probably because someone gave him the weird vibe you mentioned.
Considering that I was able to reuse about 90% of the code from our
products core packages in a newer Delphi we were in good shape. This
meant we now had the capability of producing new programs and porting
older ones at a more reasonable time frame, without breaking the
company budget, or halting current developments for extended periods of
time. I also managed to get the older and newer programs talking to
each other so our users could launch any newer or older programs from
either application in a relatively seamless manner. In many other
development environments that can be a difficult thing to do.
I explained that we were in a good position since we weren't stuck with
having to stop and drop everything at once to do complete rewrite.
Instead we had the flexibility to update our systems incrementally
which means he can keep selling new products thus making money, and
planning new developments with cool new stuff. He was very pleased to
hear that.
I've mostly ignored the waves of fear and uncertainty over the years
with Borland and Delphi since companies and technology always change
anyway. After all has there ever been a company that has never faced
criticism or uncertainty about their future? Sure I think there is
room for improvement for Borland/Code Gear and Delphi, but that's for
another thread, another day...
Good luck in whatever decision you make.
Just last year built a TCP server projects to interface with a Phone
System vendor and a 3rd party Point-of-sale vendor. It ended up being
much easier in Delphi than I first expected. I'd just thought I would
mention that since in a way it may be similar to what you are doing.
-- Ray A.
Erwin van den Bosch
<stref...@a.fake.email.com> wrote:
>Erwin van den Bosch wrote:
>> A small company can be a good company. But the problem is that if you
>> build large applications with Delphi you get very dependable of
>> Codegear. Small companies don't like that. Big companies won't even
>> consider Delphi.
>
>To name two, Yahoo and Skype use Delphi and their not what I consider small.
>
>http://www.stevetrefethen.com/blog/YahooGoForTVYeahItsWrittenInDelphi.aspx
>
>http://www.stevetrefethen.com/blog/SkypeYeahItTooIsWrittenInDelphi.aspx
>
>For a larger list I'm sure DavidI could help.
I doubt Skype for WinCE, OSX and Linux is written in Delphi!
But some big companies started with Delphi years ago. Borland was also
somewhat bigger at that time. Now CodeGear is a small company. If you
are the manager/ceo of a big company (say Adobe) then you think twice
to choose Delphi for your main products. Because you get very
dependable of a small company. What will happen when CodeGear closes
the doors?
Choosing c++ is much saver. And if you would like to make a version of
your app for OSX (like Adobe does) it's the only way to get that
easily done.
Another thing not to choose Delphi is: When Delphi 1.0 came out.
Borland created something that was years in the future. There was no
serious RAD tool like Delphi 1. Now years later: Borland was late with
supporting Windows XP, there is no Vista ready version of Delphi,
there is no 64 bit version. Delphi 8 and BDS 2005 where horrible.
Kylix was very expensive and version 1 and 2 where Alpha quality.
Borland forced a lot of developers to use Interbase instead of the BDE
(Paradox). They dropped the BDE and make Interbase opensource. But
when developers started converting there applications to Interbase,
Borland changed his mind and let everyone pay for Interbase licenses.
Just when we make a start with adapting our library to Kylix 3 Borland
pull the plug out.
And that's what you get as small or big company when you are totally
dependable of a developer tool vendor. And that's the reason why our
company for 90% sure will leave Delphi and switch to msvs.
--
Erwin van den Bosch
TNG applications
Guillem
>
> I doubt Skype for WinCE, OSX and Linux is written in Delphi!
maybe the Linux version is written in FPC or Lazarus, who knows :-)
>
> But some big companies started with Delphi years ago. Borland was also
> somewhat bigger at that time. Now CodeGear is a small company. If you
> are the manager/ceo of a big company (say Adobe) then you think twice
> to choose Delphi for your main products. Because you get very
> dependable of a small company. What will happen when CodeGear closes
> the doors?
on this I'd like to point out that:
- "when Codegear closes" should IMHO be "if Codegear closes"
- the dependability comes not from the fact that Codegear is small.
Using .NET makes you directly or indirectly dependant on Microsoft,
whether you like it or not, and they are BIG.
- the dependability also does not (fully) come from the fact that
Delphi is "propietary". Free Pascal is cross-platform and may become a
good choice if Codegear does not continue.
- even if all goes wrong and Codegear disappears, that does not mean
your company or any other that uses Delphi will disappear. Some of them
would port their apps to other environments. Maybe Delphi would become
open-source. Who knows. But hey, there are people still programming
with Delphi 3!
>
> Choosing c++ is much saver. And if you would like to make a version of
> your app for OSX (like Adobe does) it's the only way to get that
> easily done.
to get cross-platform easily done, yes.
>
> Another thing not to choose Delphi is: When Delphi 1.0 came out.
> Borland created something that was years in the future. There was no
> serious RAD tool like Delphi 1. Now years later: Borland was late with
> supporting Windows XP, there is no Vista ready version of Delphi,
> there is no 64 bit version. Delphi 8 and BDS 2005 where horrible.
> Kylix was very expensive and version 1 and 2 where Alpha quality.
> Borland forced a lot of developers to use Interbase instead of the BDE
> (Paradox). They dropped the BDE and make Interbase opensource. But
> when developers started converting there applications to Interbase,
> Borland changed his mind and let everyone pay for Interbase licenses.
> Just when we make a start with adapting our library to Kylix 3 Borland
> pull the plug out.
they've done some things wrong, yes. But they have also changed more
things in the last months than in the last 3 years. IMHO they still
deserve an opportunity. Changing all the wrong things will surely
require more time.
Said that, I understand that some people and companies simply do not
believe anymore in those promises or can not wait.
>
> And that's what you get as small or big company when you are totally
> dependable of a developer tool vendor. And that's the reason why our
> company for 90% sure will leave Delphi and switch to msvs.
and what is the difference between being dependant on Codegear or being
dependant on Microsoft?
While Microsoft has more chances to "stay", they also have an
well-gained fame of leaving people in the cold. Remember VB to VB.NET,
for example...
--
Best regards :-)
Guillem Vicens Meier
Dep. Informatica Green Service S.A.
www.clubgreenoasis.com
--
Contribute to the Indy Docs project: http://docs.indyproject.org
--
In order to contact me remove the -nospam
Brian Moelk
>> I doubt Skype for WinCE, OSX and Linux is written in Delphi!
>
> maybe the Linux version is written in FPC or Lazarus, who knows :-)
http://en.wikipedia.org/wiki/Skype
"The Skype code is closed source, and the protocol is not standardized.
The Windows user interface was developed in Pascal using Delphi, the
Linux version is written in C++ with Qt, and the Mac OS X version is
written in Objective-C with Cocoa.[2] Parts of the client use Internet
Direct (Indy), an open source socket communication library."
[...]
> - even if all goes wrong and Codegear disappears, that does not mean
> your company or any other that uses Delphi will disappear. Some of them
> would port their apps to other environments. Maybe Delphi would become
> open-source. Who knows. But hey, there are people still programming
> with Delphi 3!
Exactly: Who knows. This is what big companies do not like. Even if
"who knows" is true for every company, big or small, perception is
reality in this case.
>> Choosing c++ is much saver. And if you would like to make a version of
>> your app for OSX (like Adobe does) it's the only way to get that
>> easily done.
>
> to get cross-platform easily done, yes.
And what does Java provide?
bee
> Choosing c++ is much saver. And if you would like to make a
> version of your app for OSX (like Adobe does) it's the only
> way to get that easily done.
Maybe C++ is much saver, but it's not saving your development time and cost. Then, try to switch to FPC, it'll save your time and cost. About Adobe example, there's a great application build using FPC, and -IMO- it competes with Adobe Photoshop very well, plus it's available on most current modern OSes. Its name is Pixel (http://www.kanzelsberger.com/).
> And that's what you get as small or big company when you are
> totally dependable of a developer tool vendor. And that's the
> reason why our company for 90% sure will leave Delphi and
> switch to msvs.
Why most companies use PHP and not afraid of being left? Because PHP is an open source product and has large community supporting it. This'd be the same case if we (Delphi developers) switch to FPC. There's no need to be worried about future assurance, because FPC is also an open source product with large community base (including us). Even Indy components is supporting FPC/Lazarus, its just a matter of time before IntraWeb will also support FPC/Lazarus (since IntraWeb framework is build upon Indy).
-Bee-
bee
From your own conclusion of comparison of the 3 candidates, I believe the answer is clear enough. Get your job done fast and clean using Delphi! :D
Again, from your own statements, Delphi technically beats the others. The cons is not technical at all, IMO. The first and third cons of Delphi is easily got covered by FPC/Lazarus (free open source alternative for Delphi) when somehow Delphi owners is out of bussiness. There's nothing to be worried about the future.
Plus, you'll get native multiplatform support if your application is build using Delphi AND FPC/Lazarus (both are quite compatible). Since your software is very much related to hardware and network, a native application is almost a must to make it run fast. So, forget languages that require bloated virtual machine, like .Net and Java.
Hope this helps. :)
-Bee-
Brad White
news:45c8...@newsgroups.borland.com...
>> All I can tell you is once you start serious
>> development with Delphi your other options will pale in
>> comparison.
>>
>
> Especially when doing Compact Framework, WPF or WCF development. Then
> Delphi really rocks!
>
--
Thanks,
Brad.
Brian Moelk
> Plus, you'll get native multiplatform support if your application is
> build using Delphi AND FPC/Lazarus (both are quite compatible).
Lazarus isn't compatible with Delphi in many ways. FPC is closer. But
it's the RAD/GUI designer and associated components that make them
incompatible.
IMO, there's nothing necessarily "wrong" with this incompatibility; it
is because of the different design goals Lazarus embraces that causes
this incompatibility. But your implication of being able to easily move
between the two is misleading IMO.
Robert Giesecke
>
> It's great piece of code from Andreas Hausladen!
> Many thanks Andy!
>
Yep, I am using it, too.
Great piece of code, indeed. :-)
Dario Tiraboschi
> Yes, I too look forward to the day that I can ship a single EXE.
> Currently, my VB app consists of the main project, several COM DLL's,
> and one ActiveX EXE server (to provide the multithreading support,
> which in VB had to be an out-of-process server). The low hanging
> fruit *seems* like it would be the DLL's and ActiveX exe. Since
> those chunks are pretty well isolated currently, they may be a good
> place to start porting.
>
> I'm no fan of COM, since it was a source of distribution headaches for
> me, but it may be the quickest route for now...
>
Hi Gareth,
Multithreading stuffs?
Have a look at the unit AsyncCall:
http://andy.jgknet.de/blog/exit.php?url_id=80&entry_id=41.
It's great piece of code from Andreas Hausladen!
Many thanks Andy!
Regards
Dario
--
Andrea Raimondi
> Hello folks,
Hey Gareth!
> My apologies in advance, this is a somewhat lengthy post...
No worries. We love insightful posts.
> I am not what you would consider a professional programmer, since I
> lack any formal training (other than a couple of comp sci classes I
> took while earning my degree in theatre!). However, the company I run
> makes its business by developing and selling Ethernet-enabled motor
> control devices and control software for use in live entertainment
> (musical performances, etc.). We split our time between developing
> electronic gadgets, firmware, machinery, and desktop software.
Luckily, "professional programmers" and "formal training" have
very little in common, if anything. I've seen many "degree-endowed"
people write awful code and the other way around, thus methinks that
those two things are unrelated.
> So, from what I've learned throughout my meanderings the tools stack up
> like this:
>
> ***Java (with Netbeans RCP)***
> Pros:
> * Extremely well documented. Easy to find answers to questions.
>
> * Vast class library. Many times things you want to do, are already
> implemented (if you can find them).
>
> * Swing is a very flexible & powerful GUI toolkit with a well-designed
> API.
>
> * Cross platform.
>
> * Garbage collection relieves some responsibility.
>
> * Easy sockets & multi-threading.
>
> Cons:
> * Somewhat convoluted. As a gut reaction, it takes 2x-3x the amount of
> code to get something done compared to VB. I'm sure it's cleaner
> programming, but every task requires a long chain of classes &
> interfaces.
Personally, I've grown to dislike Java.
It's counter-intuitive to say the least.
Not that I know it particularly well, but I was ignorant of VB as
well after many years working with Delphi, but I picked it up
very soon. I also know some(not commercially) C++ and I don't
find it as complicated as Java.
That's probably going to have me shot dead from other folks
here :-), but that's my experience.
> * Swing is almost *too* flexible. I've been using the Netbeans Rich
> Client Platform to get a basic framework to give some guidance. The
> Netbeans RCP is pretty good, but it is also complex (like the base Java
> libraries). Unfortunately, unlike the base Java libraries, the
> Netbeans RCP isn't terribly well documented which can be frustrating.
Swing is one of those things that must have been designed(and developed)
when participating to a rave party and while using drugs all over.
That is, my opinion :D
> Trying to remember how to paint bold text in a JTable in Java sends me
> thumbing back through my code to find the various subclasses required.
This sends cold shivers of memories, I totally feel the pain.
> ***Delphi***
> Pros:
> * Feels familiar. It doesn't seem terribly different than VB6. In
> fact, in many ways it's the VB I wished I had (though I didn't know
> about it during our version 1.0 development!) It's got a good mix of
> procedural programming and OO.
One main difference with VB is that it's *completely* strong
typed, you can only have loose typing if you really want to,
although you'll find out that this is a firmly discouraged
practice as - unlike VB - Delphi has a very good string
management and you can do pretty much what you want using
strings rather than variants.
The latter will mostly be useful on COM, which you're willing to
abandon anyway.
I've done COM and delphi classes in the same project(see this:
http://www.andrearaimondi.net/index.php?entry=entry070207-002523),
thus I know what I'm talking about when I'm telling you that your
easiest path is converting your code to Delphi classes and use
those inside your COM wrappers.
> Cons:
> * Proprietary language. I feel a bit burned by the VB6 debacle, and
> that makes me gunshy of tieing myself to another single-source
> language/tool.
As others have already pointed out, there's Lazarus and FPC.
I also have consulted in porting a quite complex framework to that
platform from Delphi. It was done in a few hours. This should
hint at how easy it is.
> * Weird vibe surrounding the company & future development. There's
> obviously a lot of history between Borland and the customer base, I'm
> not sure what all has happened of the years but there's a tangible
> bitterness towards the company.
LOL!
Borland has been doomed so many times in 20years and counting that,
really, it should be a hint.
> ***.Net***
> Pros:
> * Possible Interop strategy to gradually port the VB application. I'm
> not sure if this is techincally smart, but it certainly sounds nice to
> avoid doing the 'big port' all at once.
Interop? That is, adding another layer on top of another layer on
top of another layer...? Are you serious?
> * Breadth and depth of class library is on par with Java.
Most concepts are "incredibly similar" to the Delphi ones, oh and by
coincidence, the original Delphi architect now works for MS and is the
brain behind C#... go figure...
> Cons:
> * Winforms is deprecated? I can't find a straight answer on this one,
> but it is awfully confusing to hear the yet again the 'next big thing'
> from MS is being deprecated. Its confusing to figure out what GUI
> toolkit MS is recommending for development today, that has a shelf life
> of at least 5 years.
Ok, let me tell you: dotNET 1.1 classes can be called and used by
2.0 ones and the other way around.
And guess what? Delphi can do single-source Win32/NET1.1 :-)
See the difference now?
> * WPF looks like it has questionable merits. I've seen some demos on
WPF is incredibly brighty :-)
> * Fool me once, shame on you. Fool me twice shame on me. I'm still a
> little aggravated that my VB6 investment is somewhat wasted.
LOL, I got to write this sentence down for future reference.
I just love it.
> would have chosen VB6. Therefore, I'm trying to do a better job of
> soliciting advice as I head down this same road again (albeit 5 years
> later).
My advice:
Use Delphi, *but* keep yourself current on C#.
This way, you save your code, because you can still use the dotNET 1.1
assemblies with 2.0 apps, and... oh... did I tell you BDS does C# as
well? :D
Besides, some long awaited features should be available by this year,
thus you can start now and at the most re-target yourself later on.
I know this may seem anti-economic, but in such a fast moving world,
that's your best option.
Keep in mind, also, that you'll have *more* than just a few problems if
your apps also target Win98 and use dotNET straight away.
> If you made it this far along in the message, thank you very much for
> your time and attention. Any advice is greatly appreciated.
These are just my 2c,
Andrew
--
You can subscribe my blog at
http://www.andrearaimondi.net/rss.php or
http://www.andrearaimondi.net/atom.php
Gareth Conner
> Hi Gareth,
>
> Multithreading stuffs?
>
> Have a look at the unit AsyncCall:
> http://andy.jgknet.de/blog/exit.php?url_id=80&entry_id=41.
>
> It's great piece of code from Andreas Hausladen!
> Many thanks Andy!
>
> Regards
> Dario
Thanks Dario for pointing out that link. And, of course, thanks to
Andy for the code!
This morning I have been looking into threading in Delphi, and have
found a few key differences between TThread and threading in .Net &
Java. In particular, there doesn't seem to be a method similar to
Control.BeginInvoke (in .Net) or SwingUtilities.invokeLater (in Java).
Both of these offer a way to post requests to update GUI elements in
the main thread in an asychronous fashion. Since a thread may kick off
some events or callbacks without knowing whether or not those events
may lead to changing a VCL component, it seems odd to have a blocking
Synchronize method as part of the TThread class. At first blush, this
seems to increase the opportunity for deadlock situations.
Searching the b.p.d.l.general newsgroup turned up several
recommendations for using the PostMessage API. I'm not familiar with
that API, but at least it gives a hint to some starting points.
Perhaps the link will shed some light on this issue for me. Thanks
again!
Wayne Niddery [TeamB]
> Gareth Conner wrote:
[overquoted material snipped]
> I used to be a VB6 programmer about 7 years ago and I have to say
> switching to Delphi was a good decision.
[...]
Ray, please trim quoted material to the minimum required for context.
--
Wayne Niddery - Winwright, Inc (www.winwright.ca)
"At the apex of every great tragedy of mankind there stands the figure
of an incorruptible altruist." - Ayn Rand
Andrea Raimondi
> Searching the b.p.d.l.general newsgroup turned up several
> recommendations for using the PostMessage API. I'm not familiar with
> that API, but at least it gives a hint to some starting points.
> Perhaps the link will shed some light on this issue for me. Thanks
> again!
<spot mode="shameless">
You may also want to check out this:
http://cc.codegear.com/Item/22921
from me, which shows two threads and label updates in a form.
</spot>
Cheers,
Guillem
>
> http://en.wikipedia.org/wiki/Skype
>
> "The Skype code is closed source, and the protocol is not
> standardized. The Windows user interface was developed in Pascal
> using Delphi, the Linux version is written in C++ with Qt, and the
> Mac OS X version is written in Objective-C with Cocoa.[2] Parts of
> the client use Internet Direct (Indy), an open source socket
> communication library."
>
nice to know. Thanks for the info Brian :-)
>
> [...]
> > - even if all goes wrong and Codegear disappears, that does not mean
> > your company or any other that uses Delphi will disappear. Some of
> > them would port their apps to other environments. Maybe Delphi
> > would become open-source. Who knows. But hey, there are people
> > still programming with Delphi 3!
>
> Exactly: Who knows. This is what big companies do not like.
Agreed, but that does not mean Microsoft is better in this point. While
they surely will be around for a long long time, they have left people
out in the cold before and I would not be surprised if they would do it
again. For example, I do not think all VB developers are happy about
the transition to VB.NET.
Anyway, my point was that if Codegear would disappear tomorrow, none of
their clients would disappear the day after tomorrow because of that.
They would need to adapt and prepare for change, yes, but nothing more.
> Even if
> "who knows" is true for every company, big or small, perception is
> reality in this case.
not sure what you mean with this.
--
Best regards :-)
Guillem Vicens Meier
Dep. Informática Green Service S.A.
Dario Tiraboschi
>
> Thanks Dario for pointing out that link. And, of course, thanks to
> Andy for the code!
>
> This morning I have been looking into threading in Delphi, and have
> found a few key differences between TThread and threading in .Net &
> Java. In particular, there doesn't seem to be a method similar to
> Control.BeginInvoke (in .Net) or SwingUtilities.invokeLater (in Java).
> Both of these offer a way to post requests to update GUI elements in
> the main thread in an asychronous fashion. Since a thread may kick
> off some events or callbacks without knowing whether or not those
> events may lead to changing a VCL component, it seems odd to have a
> blocking Synchronize method as part of the TThread class. At first
> blush, this seems to increase the opportunity for deadlock situations.
>
> Searching the b.p.d.l.general newsgroup turned up several
> recommendations for using the PostMessage API. I'm not familiar with
> that API, but at least it gives a hint to some starting points.
> Perhaps the link will shed some light on this issue for me. Thanks
> again!
there are a lot of sources!
Two that come in mind are:
http://www.midnightbeach.com/jon/pubs/MsgWaits/MsgWaits.html by John
Shemitz
Multi-threaded programming contest winners:
http://dn.codegear.com/article/29786
The winner, Mandelbrot Explorer, makes thread synchronisation using
windows messages (PostMessage API ) and doesn't use synchronize (no
thread blocking).
Dario
Gareth Conner
> Swing is one of those things that must have been designed(and
> developed) when participating to a rave party and while using drugs
> all over. That is, my opinion :D
Perhaps, though it also gives the impression of being designed by some
very smart folks with PhD degrees and lots of time. Its architecture
is beautiful, difficult to use correctly, and near impossible to code
rapidly.
> This sends cold shivers of memories, I totally feel the pain.
LOL!
> One main difference with VB is that it's completely strong
> typed, you can only have loose typing if you really want to,
> although you'll find out that this is a firmly discouraged
> practice as
Yes, and I'm glad to use a strongly-typed language. I generally
succeeded in avoid the loose-typing in VB. Though it was eye-opening
to find the aspects of VB that work against strong-typing efforts
behind your back.
> I've done COM and delphi classes in the same project(see this:
> http://www.andrearaimondi.net/index.php?entry=entry070207-002523),
> thus I know what I'm talking about when I'm telling you that your
> easiest path is converting your code to Delphi classes and use
> those inside your COM wrappers.
Thanks for that, I'm interested in the approach and it's good to hear
that it works.
> LOL!
>
> Borland has been doomed so many times in 20years and counting that,
> really, it should be a hint.
I've done a little searching through the newsgroup archives, and I can
see your point. There seems to have been dire predictions for quite a
few years, but Codegear is still on its feet.
> Interop? That is, adding another layer on top of another layer on
> top of another layer...? Are you serious?
Well...when you say it like that it doesn't sound so good :)
> And guess what? Delphi can do single-source Win32/NET1.1 :-)
> See the difference now?
Does that happen through Interop as well? Are there drawbacks to
taking advantage of .Net sockets & threading API's and using straight
VCL for the GUI? Or is that approach just asking for trouble?
Or are saying that you can share a single codebase and compile for
either Win32 or .Net? In that case, I suppose you just need to be
careful not to use any FCL classes or Win32 calls directly, right?
> These are just my 2c,
>
> Andrew
Thanks Andrew, I appreciate your thoughts.
Brian Moelk
> Agreed, but that does not mean Microsoft is better in this point. While
> they surely will be around for a long long time, they have left people
> out in the cold before and I would not be surprised if they would do it
> again. For example, I do not think all VB developers are happy about
> the transition to VB.NET.
I agree, and that is what I meant by my statement below. There are no
guarantees things will actually be better simply because one chooses a
larger vendor/community.
> Anyway, my point was that if Codegear would disappear tomorrow, none of
> their clients would disappear the day after tomorrow because of that.
> They would need to adapt and prepare for change, yes, but nothing more.
Yes, but FUD is a big reason why people make decisions. Simply
identifying it as FUD is not sufficient to neutralize it.
>> Even if
>> "who knows" is true for every company, big or small, perception is
>> reality in this case.
>
> not sure what you mean with this.
What I mean is that I basically agree with your rational argument:
choosing a large vendor/community isn't necessarily going to be better.
There are no certainties in any of this stuff.
I was making the point that some decisions are made based in part on
irrational reasons. This is especially true of purchasing decisions and
decisions made by large companies in regards to selecting other large
companies. It seems to me that birds of a feather flock together (big
companies like to buy stuff from other big companies).
OTOH, there are some very rational reasons why choosing a large
company/vendor or a large community is advantageous to a
proprietary/small vendor with a relative small user base.
Gareth Conner
> Two that come in mind are:
>
> http://www.midnightbeach.com/jon/pubs/MsgWaits/MsgWaits.html by John
> Shemitz
>
> Multi-threaded programming contest winners:
> http://dn.codegear.com/article/29786
>
> The winner, Mandelbrot Explorer, makes thread synchronisation using
> windows messages (PostMessage API ) and doesn't use synchronize (no
> thread blocking).
>
> Dario
This is great stuff, thanks for the links. If my post has proven
nothing else to me, I now know that the Delphi folks respond to
questions with useful info!
Andrea Raimondi
> Thanks for that, I'm interested in the approach and it's good to hear
> that it works.
Yes it does.
> I've done a little searching through the newsgroup archives, and I can
> see your point. There seems to have been dire predictions for quite a
> few years, but Codegear is still on its feet.
Yeah, and still wholly owned by Borland, so what? :D
> Well...when you say it like that it doesn't sound so good :)
Yeah, I bet <g>.
> Does that happen through Interop as well? Are there drawbacks to
> taking advantage of .Net sockets & threading API's and using straight
> VCL for the GUI? Or is that approach just asking for trouble?
I'm not sure, I've (almost) never been asking for trouble using
Delphi <g>(ok, this one was a bit nasty... :P)
I really don't know, I mostly use either/or and mixing them
never crossed my mind because I never needed it(hint, hint...).
> Or are saying that you can share a single codebase and compile for
> either Win32 or .Net? In that case, I suppose you just need to be
> careful not to use any FCL classes or Win32 calls directly, right?
Right, you have two approaches here:
1) Use conditional defines and compile your source accordingly,
2) Have a base abstract class and inherit descendants. This
approach should be working for the largest majority of cases.
There's however something to note: between Win32 and dotNET
some things change quite prominently, such as GUIDs: while in
Delphi Win32 you have a way of specifying them, in Delphi.NET you
should be following dotNET rules(i.e. a GUID attribute).
You better research for the other "weirdnesses".
At last, it's worth noticing that you'll use GUIDs in D32
only when you want reference count(i.e. most of the times),
while in dotNET they're optional(so you may want to avoid
refcount altogether in both worlds).
When I'm saying "prominently" that should be intended as "won't
compile".
Oh and just by dropping a stone in the water: many Delphi
applications run smoothly on Linux using Wine... :-)
> Thanks Andrew, I appreciate your thoughts.
You welcome :D
Andrea Raimondi
> This is great stuff, thanks for the links. If my post has proven
> nothing else to me, I now know that the Delphi folks respond to
> questions with useful info!
Just as a side note and a reminder:
I guess this is what Peter Morris was referring to when saying
"Personally I have found that the people in the newsgroups are
probably 10 times more helpful than in the MS ones, despite
there being a fraction of the total number of users."
Dave Keighan
> > Multi-threaded programming contest winners:
> > http://dn.codegear.com/article/29786
For no other reason that it's fun to play with [I do hope to learn from
the code when I get to that stage] my fav is:
Building pyramids with cooperative worker threads by Denis Portilho.
--
Dave
Ingvar Nilsen
> Searching the b.p.d.l.general newsgroup turned up several
> recommendations for using the PostMessage API. I'm not familiar with
> that API, but at least it gives a hint to some starting points.
As I said in another reply to you. Delphi is closer to the metal than
.Net. You don't have to use the Win API, but it is always there, ready
to be used.
Basically, all controls are windows, the main form, a button, an edit
box, a panel - they are all windows, mostly being "owned" by another
window further up in the hierarchy.
In the Windows OS all windows have a process that runs in a loop. In
these loops, the message queue is scanned for new messages all the
time. In general, there are two ways to pass a message to a window,
PostMessage()
SendMessage()
Using SendMessage, the process sets aside all pending tasks and throws
itself at the incoming message and handles it immediately.
With PostMessage OTOH, the process first gets pending work done, the
incoming message has to politely sit and wait for its turn.
Thats why PostMessage is good for threads, there is no collision
because the OS self organises the work.
In Delphi, this is very easy to implement, when you see it, you will
understand it, Delphi has excellent support for declaring message
handlers and also message loops running that you can hook into.
Mark Reichert
news:45c9eaa2$1...@newsgroups.borland.com...
>> * Fool me once, shame on you. Fool me twice shame on me. I'm still a
>> little aggravated that my VB6 investment is somewhat wasted.
>
> LOL, I got to write this sentence down for future reference.
> I just love it.
I thought it was "Fool me once, shame on-shame on you. Fool me-you can't get
fooled again." :)
Iman L Crawford
@newsgroups.borland.com:
> Fool me-you can't get
> fooled again." :)
you forgot the power chord.
--
Iman
Tony Caduto
>
> I think you underestimate what's available for Java and .NET.
>
> MfG
> twm
Well, last time I looked at .net stuff I could not find open source or
free equivalents to what I had been using in Delphi.
Tony Caduto
> Especially when doing Compact Framework, WPF or WCF development. Then
> Delphi really rocks!
>
Don't really care about that stuff right now, so it's not relevant to
me.
Tony Caduto
> This morning I have been looking into threading in Delphi, and have
> found a few key differences between TThread and threading in .Net &
> Java. In particular, there doesn't seem to be a method similar to
> Control.BeginInvoke (in .Net) or SwingUtilities.invokeLater (in Java).
> Both of these offer a way to post requests to update GUI elements in
> the main thread in an asychronous fashion.
That is a piece of cake in Delphi,
you simply create a message handler in the main form and then in your
threads you use PostMessage to send back messages to the MainForm, or
any form for that matter.
What is really cool is you can type cast a object created in a thread to
a integer and pass that integer back to the GUI and then "reconstitute"
the object. You can use your own object or something like a
tstringlist. Using this method you can pass anything you like back from
the thread to the GUI.
In your main form ( or a common shared unit) create constant
message ID. If you don't put it in a common shared unit add it to the
unit you have your thread in. I try to keep all my thread classes in
separate units as it's easier to keep track of.
const
DM_QUERYDONE = WM_USER + 402;
Then in the private section create a procedure declaration.
procedure DMclosetab(var Message: TMessage); message DM_QUERYDONE;
Then hit ctrl+shift+C to complete the class.
You then end up with:
procedure Tmainform.DMQUERYDONE(var Message: TMessage);
var
params:tstringlist;
firstname,lastname:string;
begin
try
params:= tstringlist(message.lparam);
firstname:= params.values['first_name'];
lastname:= params.values['last_name'];
finally
if assigned(params) then
freeandnil(params);
end;
end;
Now in your thread you can use postmessage to communicate back to the
main GUI.
params:=tstringlist.create;
params.values['first_name']:='Tony';
params.values['last_name']:='Soprano';
postmessage(mainform_handle,DM_QUERYDONE,nil,integer(params));
This is a example from one of my apps that executes a query in a thread
and then sends back the status of the query to the main program i.e.
error info, rows affected etc. For purpose of example I just returned a
first and last name.
Tony
Tony Caduto
>
> Thanks for these links, I hadn't heard of them before. The only socket
> library I had heard of was Indy (since it's included with Delphi).
> I'll certainly take a look at these options
> Thanks for the response, it's great to hear the enthusiasm!
>
There is lot's more stuff out there.
Every time I think I want to do something in .net or Java and I actually
start I end up doing tons more work than if I had simply done it in Delphi.
Everyone talks up the database connectivity in .net, but I just don't
see it being better or more productive than Delphi's tdataset or dbexpress.
Gareth Conner
>
> This is a example from one of my apps that executes a query in a
> thread and then sends back the status of the query to the main
> program i.e. error info, rows affected etc. For purpose of example I
> just returned a first and last name.
>
>
> Tony
Thanks a bunch, this example and some of the others posted today should
get me rolling. You've been a huge help, thanks!
Jon Springs
ROTFLMYO!
You do an amazing imitation of our beloved president.
-----Jon-----
--
-----Jon-----
"Mark Reichert" <ma...@messagelink.com> wrote in message
news:45ca21bf$1...@newsgroups.borland.com...
bee
> Lazarus isn't compatible with Delphi in many ways. FPC is
> closer. But it's the RAD/GUI designer and associated components
> that make them incompatible.
If what you mean is a full (100%) compatibility, then neither Lazarus or FPC is fully compatible with Delphi.
> IMO, there's nothing necessarily "wrong" with this
> incompatibility; it is because of the different design goals
> Lazarus embraces that causes this incompatibility. But your
> implication of being able to easily move between the two is
> misleading IMO.
I never said it would be easy. It depends on your code whether it tights very much with OS API or just pure pascal calls (using RTL/VCL/FCL/LCL). If the last is the case, it wouldn't be a hard work to move to FPC/Lazarus, sometimes it's just as easy as recompile. It'll be lots easier if you write code using Delphi but maintain the compatibility with FPC/Lazarus since the day one, or vice versa.
-Bee-
Jon Springs
ROTFLMAO
--
-----Jon-----
"Jon Springs" <jspringsATjontandsheDOTorg> wrote in message
news:45ca9cb5$1...@newsgroups.borland.com...
Tony Caduto
>
> Have a look at my site - written in ASP.Net 2.0, marketing a free
> Delphi tool <g>
>
Ingvar,
Your site looks great :-)
Now check out mine built with PHP(Drupal) and Marketing Delphi built
shareware :-)
Tony Caduto
AM Software Design
Home of Lightning Admin for Postgresql and MySQL
http://www.amsoftwaredesign.com
Tony Caduto
>
> Remember, there is only one reason to use .NET: it improves developer
> productivity.
I don't know why people keep saying this, it (.net) does not provide any
more productivity than you can have with Delphi overall. I can see
ASP.net would give productivity gains over webbroker, but .net certainly
does not provide more in the are of desktop application development.
The majority of people use .net becasue they don't know about Delphi
plain and simple.
I recently interviewed for a job and the "Software Architect" that did
part of the interview had never even heard of Delphi. This person only
knew .net and looked scared when I talked about php,perl, and Delphi :-)
Their response was how can you possibly know more than one thing and
keep them all straight in your head.....
Tony Caduto
Ingvar Nilsen
> Steve Thackery wrote:
> > Remember, there is only one reason to use .NET: it improves
> > developer productivity.
>
> I don't know why people keep saying this, it (.net) does not provide
> any more productivity than you can have with Delphi overall.
Right and not right
> I can see ASP.net would give productivity gains over webbroker,
Right
> but .net certainly does not provide more in the are of desktop
> application development.
Right
> The majority of people use .net becasue they don't know about Delphi
> plain and simple.
IOW, still a well kept secret after 12 years
> I recently interviewed for a job and the "Software Architect" that
> did part of the interview had never even heard of Delphi.
Jepp
> This person only knew .net and looked scared when I talked
> about php,perl, and Delphi :-)
> Their response was how can you possibly know more than
> one thing and keep them all straight in your head.....
Seriously, this becomes more and more difficult. I have started to use
a technique, I do not even attempt to remember what I do one day, the
next day it is gone. Thus I have really known to appreciate
documentation, so I document also silly small things, and especially
larger projects.
The most important docs I write is overview docs on program execution
work-flows, what happens, when it happens and in what order. It helps
me a lot when coming back, the next day <G>
Ingvar Nilsen
> Your site looks great :-)
Thanks!
> Now check out mine built with PHP(Drupal) and Marketing Delphi built
> shareware :-)
How is business?
I missed only one thing - a contact us page to find out where you are.
On my site, you can even see when the sun rises :)
Apart form that, your site is very clean and easy to navigate, I like
it! (And I got some ideas..)
Still I wonder how it is to make web sites without ASP.Net..
Guillem
>
> I agree, and that is what I meant by my statement below. There are no
> guarantees things will actually be better simply because one chooses a
> larger vendor/community.
right. In my own personal experience, which may coincide with others or
not, big companies *usually* do not take in account too much what most
of their customers have to say.
Some reasons would be:
- too much information to process
- some demands imply flexibility which is not a common characteristic
of big companies.
- "what the hell knows that customer about our work?" attitude.
Although this is not exclusive from big companies.
- "I don't care if we lose you since you're small and we have a lot
more clients" attitude. Not a joke, I had this *once*.
- "we can't do that" attitude. No reason, no explanation. They simply
won't consider it. And this has happened to us a few times...
Surely there are more reasons which I don't remember now. That is why I
prefer a small or medium company if I have to choose between 2 similar
products. They usually (granted, not always) hear more to what you have
to say.
>
> Yes, but FUD is a big reason why people make decisions. Simply
> identifying it as FUD is not sufficient to neutralize it.
this is a BIG truth...
>
> I was making the point that some decisions are made based in part on
> irrational reasons.
as that philosopher said... if irrational people would fly we would not
see the sun <g>
> This is especially true of purchasing decisions
> and decisions made by large companies in regards to selecting other
> large companies. It seems to me that birds of a feather flock
> together (big companies like to buy stuff from other big companies).
IMHO usually because of post-sales requirements. While a small company
can provide a good or even better offer than a big one for a certain
product, it usually has not a post-sales department as "powerful" as
one of a big company. Note I'm not speaking about good or bad, just
"powerful".
>
> OTOH, there are some very rational reasons why choosing a large
> company/vendor or a large community is advantageous to a
> proprietary/small vendor with a relative small user base.
agreed.
Jolyon Smith
> > The majority of people use .net becasue they don't know about Delphi
> > plain and simple.
>
> IOW, still a well kept secret after 12 years
ime in the majority of cases it wasn't that they don't know about Delphi, it's
that Borland <> Microsoft.
The reason they like .net is that they think it gives them everything Delphi
could give them PLUS a nice warm Microsoftandfuzzy feeling.
The "Delphi blindness" is more often simply "Microsoft Focus". This is
understandable to an extent. There is very little that you cannot go to
Microsoft for - whether what you get is the best is a whole different matter.
The Soft Architect example was perhaps simply an extreme case of "Microsoft
Focus" rather than "Delphi (or wider) ignorance" - i.e. they simply didn't
_need_ (or feel a need) to know about those other things.
Just as most consumers are perfectly happy with DVD and remain in blissful
ignorance of HD-DVD or Blu-Ray. It's not that they are stupid, ignorant or
video quality philistines. They just don't care and don't feel compelled to
find a reason to care.
> I have started to use
> a technique, I do not even attempt to remember what I do one day, the
> next day it is gone. Thus I have really known to appreciate
> documentation, so I document also silly small things, and especially
> larger projects.
Indeed - learning to forget is an art.
:)
--
Jolyon
Brian Moelk
>> Lazarus isn't compatible with Delphi in many ways. FPC is
>> closer. But it's the RAD/GUI designer and associated components
>> that make them incompatible.
>
> If what you mean is a full (100%) compatibility, then neither Lazarus
> or FPC is fully compatible with Delphi.
FMPOV your original statement of "quite compatible" and the way you
presented Lazarus/FPC as an easy/uncomplicated transition I thought was
a bit misleading. I wanted to point out that there could be some
"gotchas" associated with compatibility issues.
The severity and pervasiveness of the "gotchas" certainly depends on the
kinds of applications one is building. But many applications that I've
built/seen will have some difficulty being ported to Lazarus/FPC if they
needed to do so today. In a few months from now, it might be a totally
different story, but as of today, there are complications.
> I never said it would be easy.
FMPOV, you implied it. I just wanted to clarify that point.
> It depends on your code whether it
> tights very much with OS API or just pure pascal calls (using
> RTL/VCL/FCL/LCL). If the last is the case, it wouldn't be a hard work to
> move to FPC/Lazarus, sometimes it's just as easy as recompile.
AFAIK, Lazarus has difficulty with most of the main third party
components that people use.
Again, someone might perceive they are simply "using the VCL" and might
have believed based on your statements that it's as easy as a recompile,
but it's not. I just want to put the enthusiasm for Lazarus/FPC in its
proper context.
I too like FPC. I'm less optimistic regarding Lazarus; but I'm very
willing to keep an open mind regarding those efforts and see what
happens. I wish everyone the best of luck since the community will
benefit from better tools no matter how they come about.
> It'll be
> lots easier if you write code using Delphi but maintain the
> compatibility with FPC/Lazarus since the day one, or vice versa.
Agreed 100%. IMO, if one is thinking about using FPC/Lazarus as a "Plan
B", it makes sense to explore what it would take to execute on that plan
as the project develops. This way, platform and tool compatibility
issues can be abstracted/separated out to a large degree.
Gareth Conner
> Seriously, this becomes more and more difficult. I have started to use
> a technique, I do not even attempt to remember what I do one day, the
> next day it is gone. Thus I have really known to appreciate
> documentation, so I document also silly small things, and especially
> larger projects.
>
> The most important docs I write is overview docs on program execution
> work-flows, what happens, when it happens and in what order. It helps
> me a lot when coming back, the next day <G>
I agree, I have really grown to appreciate documentation as well.
Besides the specific code documentation, for the last few years I've
also kept a development journal where I jot down what was accomplished
that day and what I hope to accomplish the next. Of course my
aspirations for the next day are seldom fulfilled :)
Andrea Raimondi
Sorry if I'm emailing you, I simply wanted to know what you chose
after the whole discussion :-)
Gareth Conner
> Hi Gareth,
>
> Sorry if I'm emailing you, I simply wanted to know what you chose
> after the whole discussion :-)
>
> Andrew
Hi Andrew,
No problem, did you send an email to me? My apologies, I must have
missed it (better check my spam folder!).
I haven't actually reached a conclusive decision. I'm still doing some
tests with Delphi and more reading/research. I bought the book on Indy
sockets from AtoZed, and just received my disc that has the entire
collection of Delphi Magazine articles. It looks to have several
really good articles regarding threading and the producer-consumer
pattern.
I've got a small list of questions brewing that I may post to one of
the tech newsgroups, but I'll see if I can't find the answers myself
before burdening folks anymore.
The only hesitations that have grown for me regarding Delphi are:
1. The IDE has crashed a few times this past week, maybe once or twice
a day. I haven't pinned down any repeatable problem, but I've just
been working through some simple socket tests (console type tests) and
a few online tutorials. The IDE may get more stable as I become more
familiar, and do fewer silly things. I've read posts stating that
ErrorInsight can cause issues, but I really really really like
ErrorInsight. As a newcomer, it's great to see compile-time errors in
real-time. Most Java IDE's have this feature too, and I've found it
saves me tons of time.
2. The lack of a good cross-platform solution has been causing me more
thought than I anticipated. Yesterday, for fun, I made a distribuition
out of the code I had been working on in Netbeans and launched the jar
on my iMac and a Linux VM. Everything worked as expected, even though
I had been developing on WinXP. I know it SHOULD work, but it's
impressive to see it really work transparently. I'm trying to not let
this influence my thought too much. In the end, the vast of majority
of my customers are perfectly happy running Windows.
Anyhow..,thanks for all your help, and sorry again if I missed your
email.