delphi - some problems 
Author Message
 delphi - some problems

Quote:

> [...]
> 2) VB has 'control arrays' - if I have 30 identical fields on a form
> I need only one event procedure. delphi doesn't have control arrays.
> Any idea how to handle that without writing 30 identical procedures?
> [...]

Multi-select the fields and then go to the event's page and select
the method you want to handle their event.  For example, if you have
30 TEdit's and want all their OnKeyDown events to be the same, select
all thirty then go to the events page and drop down the list of
compatible methods for OnKeyDown.  If none exist you can create one
by double-clicking the event.  Now all 30 TEdit's use the same event
hanldler. (Of course you can do this by selecting them one by one,
selecting all of them at once is quicker). It is more general than
control arrays since any component on the form that has an OnKeyDown
event can use the same event handler. This would be especially useful
in the above if you wanted to make a TComboBox have the same OnKeyDown
code as a TEdit.

The other comments, about our documentation, example files,
container classes, and help files, have been noted.  We are already
working on improving those for the next version.


Delphi Development



Wed, 27 Aug 1997 01:18:46 GMT  
 delphi - some problems

    > 2) VB has 'control arrays' - if I have 30 identical fields on a form
    > I need only one event procedure. Delphi doesn't have control arrays.
    > Any idea how to handle that without writing 30 identical procedures?
    >

I'm not offering this with any warranties, but here is a posting I saw
on comp.lang.Pascal (it is talking about the equivalent of control arrays
in Delphi):

Quote:
>>rsg> How do I make a control array at design time?

>>It is quite easy. Try the following:

>>        Unlike VB, you can declare any data type you want, including
>>        an array of various component and easily initialize it in
>>        the OnCreate handler of a form. The following code declares
>>        and inits an array of labels on a form:

>>          type
>>            Labels: array[0..4] of TLabel;
>>          var
>>            I, J: Integer;
>>          begin
>>            J := 0;
>>            for I := 0 to ControlCount - 1 do
>>              if Controls[I] is TLabel then
>>              begin
>>                Labels[J] := TLabel(Controls[I]);
>>                Inc(J);
>>              end;
>>          end;

I hope you find this useful.

--
Ian Piper
--

Home page: coming soon



Thu, 28 Aug 1997 22:10:20 GMT  
 delphi - some problems


Quote:



[snip]
[snip]

Quote:

>The other comments, about our documentation, example files,
>container classes, and help files, have been noted.  We are already
>working on improving those for the next version.


>Delphi Development

Notice all. What a measured and professional response to some
constructive criticism. I think both postings have immensely improved my
understanding of Delphi, which I have yet to play with.

Basically:- it is not perfect but pretty impressive.
and Borland are responsive to criticism without getting heated up about
it. I like that, and now I definitely have to get a copy to look at.



Fri, 29 Aug 1997 09:35:32 GMT  
 delphi - some problems

Quote:

>The other comments, about our documentation, example files,
>container classes, and help files, have been noted.  We are already
>working on improving those for the next version.


>Delphi Development

No offense, Chuck...but some of us bought THIS version.  {putting on
interviewer's jacket}

What are your plans on making a knowledge base available to us
immediately? Tutorials...source code?  {taking it off} I am fully
positioned to making the rat's leap from VB to Delphi.  I've already
purchased your product and am using it in a client's application. Things
are going much more slowly than they should for a registered user of your
product.  I am determined to make this work but, for the record, am an
unsatisfied customer.  There's many more of us in the same boat.

John Reynolds



Fri, 29 Aug 1997 06:17:29 GMT  
 delphi - some problems
three days ago I posted an article about some shortcomings of Delphi.
Written on the spur of the moment - when the first frustrations set in.

Now, 72 hours later, slightly calmer view. Firstly - the perspective.
I am in. This is the best tool overall for a wide range of applications.
It has some annoying glitches, but they are very minor in comparison
to the overall tool. So, any of my comments below should be considered
in this context - if you feel like sending flames.

72 hours later, I still think that Borland                              
has a _serious_ problem on their hands.  The technical glitches (doco,  
container classes) show much deeper underlying problem: they apparently
do not understand the market. Frankly, I am worried about their future.
(Worried, because I _like_ their tools. I liked them since Turboc2.0!).

I am still going through Delphi manual.  It is not bad overall.  There          
are some things there. Their sequence of sample application description
is very well
thought out and gives a newcomer to Windows a good overview of basic
elements. I still think you need to be te techie to go through it. Why
don't they just copy VB manual? - at least in spirit.

If Delphi is aimed at ex-TurboPascal programmers they did an excellent  
job. But their objective was to capture develompent market as a whole -    
from VB to C++. This product as it is now has too many rough edges.      
It definitely has a potential to became _easily_ THE programming
environment for WindowsXXX  

The information that _beginners_ need is difficult to find.  The        
information that 'pure' VB programmers need and are used to having is      
difficult to find (this is a very serious omission if you aim for that market). The general abstract data type classes - which C++      
programmers have and use - are difficult to find (annoying - they got
some with TP7.0).                          

Borlan has an object oriented language - and they should have            
capitalize on that by producing a more complete package.  By adding a      
set of Smalltallkish/RoqueWave (in functionality) classes (as an          
_integral_ part of the package) they would create a new developer            
_standard_.  Developers would be freed from coding hash tables and other  
elementary stuff - and would appreciate it, too. With good set of
classes people considering Smalltalk, eiffel - instead of C++ - would
probably go for Delphi.

Hoping that third party will do that is not enough.  Third party will
not create a standard, Borland could but didn't.  We are still at the    
hacker level here, doing elementary coding.  With a decent set of        
standard classes developers would create derived packages of higher      
level.                                                                  

Borland has to act quickly.  Otherwise, after the initial euphoria -  
mostly by former TP users - the market will die down, as non-technical  
VB types will refuse to buy Delphi (and most VB-types are non-technical).    
And C++ types will have little incentive to switch to Delphi - they      
already know their stuff - and they are not about to recode their
ADTs to Delphi.

Overall I understand that most of my criticism is coming from a
discrepancy between my expectations of Delphi as a Holy Grail of
programming environments and the reality. The fact is that Delphi
does not fall short that much - in fact only a little.
The most annoying thing for me is that not much more work would
be required for Delphi to be an absolute killer. Anyway, I am
not doing VB any longer. Not much reason for it. Delphi is much,
much more fun.



Fri, 29 Aug 1997 08:46:16 GMT  
 delphi - some problems

Quote:

> >The other comments, about our documentation, example files,
> >container classes, and help files, have been noted.  We are already
> >working on improving those for the next version.


> >Delphi Development

> No offense, Chuck...but some of us bought THIS version.  {putting on
> interviewer's jacket}

> What are your plans on making a knowledge base available to us
> immediately? Tutorials...source code?  {taking it off} I am fully
> positioned to making the rat's leap from VB to Delphi.  I've already
> purchased your product and am using it in a client's application. Things
> are going much more slowly than they should for a registered user of your
> product.  I am determined to make this work but, for the record, am an
> unsatisfied customer.  There's many more of us in the same boat.

The improvements we are making to the help file and example programs
we plan to make available via or ftp site with links from our WWW
page (http://www.borland.com).  We are investigating the knowledge
base, and I would direct you to our Developer Relations department,
and to their Connections program.  They handle the knowledge base and
like information.

I would also recommend that if you are having trouble post questions
on the comp.lang.pascal for now, and in the Delphi news group when it
is created.  Also we do a lot of support for Delphi on CompuServe
on the DELPHI forum (GO DELPHI).


Delphi Development



Sat, 30 Aug 1997 02:03:48 GMT  
 delphi - some problems

Quote:

> The information that _beginners_ need is difficult to find.  The        
> information that 'pure' VB programmers need and are used to having is      
> difficult to find (this is a very serious omission if you aim for that market). The general abstract data type classes - which C++      
> programmers have and use - are difficult to find (annoying - they got
> some with TP7.0).                          

I agree. It would have been nice if they could have at least coordinated
some 3rd party books to be out in time for the launch to make up for
any lack in documentation.

Quote:
> The most annoying thing for me is that not much more work would
> be required for Delphi to be an absolute killer. Anyway, I am
> not doing VB any longer. Not much reason for it. Delphi is much,
> much more fun.

It's more fun and better, but the learning curve *could* have been
greased better.

andy.



Sat, 30 Aug 1997 22:33:08 GMT  
 delphi - some problems
delphi - some problems

I saw a demo of Delphi at Comdex. I was impressed, but I think it has a
major flaw that is not feature based: Pascal.  When I study to improve my
skills, I look for available market. Very few people are using Pascal in
a professional capacity. That means you educate yourself in a very
limited skill set. Re-learning Basic (which I studied in high school)
took very little time.
There is also increasing use of Basic for scripting languages which makes
it even more useful.
I think if they would have made Delphi C-based it would have been a VB
killer. As it is, however, I know very few programmers (who don't already
know Pascal) who are even looking at it for possible development.
Just my $.02 worth.

Dan



Sun, 31 Aug 1997 08:25:17 GMT  
 delphi - some problems

Quote:

> delphi - some problems

> I saw a demo of Delphi at Comdex. I was impressed, but I think it
has a
> major flaw that is not feature based: Pascal.  When I study to
improve my
> skills, I look for available market. Very few people are using
Pascal in
> a professional capacity. That means you educate yourself in a very
> limited skill set. Re-learning Basic (which I studied in high
school)
> took very little time.
> There is also increasing use of Basic for scripting languages which
makes
> it even more useful.
> I think if they would have made Delphi C-based it would have been a
VB
> killer. As it is, however, I know very few programmers (who don't
already
> know Pascal) who are even looking at it for possible development.
> Just my $.02 worth.

> Dan

In order to create a really good visual programming product
enhancements to the language that it is based on must be created.
C/C++ are highly standardized languages, and if any 3rd party will
change the language or add to it in order to support the stuff that is
needed for a visual environment, the market will not accept it.
(Borland themself had added dynamic dispatching to C++ to BC++ 3.1 for
OWL1, and a lot of people critisized them for that, so they dropped it
in OWL2, even if it makes the code messier).

Basic is virutally owned by Microsoft, that is why MS was able to add
all the stuff needed to create VB.

Pascal is virtually owned by Borland, that is why Borland was able to
add all the stuff they needed to create Delphi.

I personally love Pascal, and think it is as easy to use as basic
(usually easier because it is more streamlined), and as powerfull as
C/C++.

I also do not think that any mainstream language is too hard to
program in, Basic in VB has gone closer to what Pascal used to be,
Object Pascal has a lot of things that are close to C++, and the new
objext model in Delphi makes a lot of Delphi code look like VB code.

About the market place - Markets for programming languages are created
based on the Value per $ for a product, The C market was created
because C was very attractive for assembler programmers and offered
modern structured capability and portability, The C++ market was
created because C++ appealed to all the C programmers by offering them
a lot of new OO functionality and fixes to C, The Basic market was re-
created with VB because VB is such a great tool for fast Windows
design, and Pascal had a huge market because of the popularity of
Turbo Pascal. I'm under the impression that the benefits of Delphi
will re-create this market.

Ron.
--
Ron Loewy

HLPDK/PA - Multi-Platform Hypertext Tool, Win/HTML/OS2/DOS
Interactive Help - Interactive and Dynamic WinHelp ext.
PASTERP - Extendable Application Script Language



Sun, 31 Aug 1997 23:19:04 GMT  
 delphi - some problems

    > skills, I look for available market. Very few people are using Pascal in
    > a professional capacity. That means you educate yourself in a very
    > limited skill set. Re-learning Basic (which I studied in high school)
    > took very little time.
    >

This is a little inconsistent, don't you think? What market presence did BASIC
have before VB came along? Zippo, that's what. So why did you trouble to
(re-)learn it? Presumably because you had faith in an easy-to-use, highly productive
development system. Well, that's what Delphi is now. Only the designers had the
chance to benefit from four years of experience of a VB-using marketplace.

Delphi stands a good chance of slaughtering VB. And I speak as a hitherto
unshakeable VB bigot. All the things that were starting to niggle me about VB
(by their absence) are there in Delphi. True executables, faster running, ability
to write my own dlls, even little things like built-in resource editors (no more
iconworks!) - it's a beautifully designed, well-rounded product.

I hope the designers of VB 4 are putting in some long hours trying to claw back
some of the lost ground, because Delphi could give them some serious headaches
otherwise.

Did I mention that I like Delphi? :-)

--
Ian Piper
--

Home page: coming soon



Mon, 01 Sep 1997 14:58:58 GMT  
 delphi - some problems

Quote:

>delphi - some problems
>I saw a demo of Delphi at Comdex. I was impressed, but I think it has a
>major flaw that is not feature based: Pascal.  When I study to improve my
>skills, I look for available market. Very few people are using Pascal in
>a professional capacity. That means you educate yourself in a very
>limited skill set. Re-learning Basic (which I studied in high school)
>took very little time.

Well <disclaimer on>, I can't speak for anyone else but I've used
approx a dozen different languages in my computer work and play (does
awk count as a seperate language?). When I started out as a {*filter*}ager
in BASIC I wrote lousy programs. Why? Because I didn't know better,
it wasn't BASIC's fault. Every time I've had to adapt to a new language
I've learnt something new and been able to apply things I've learnt
before. What I'm trying to say is, the *syntax* that you use is not as
important as how you use it.

As to the market issue, all I can say is that when I finished my degree
there was NO market for VB skills (at least not in Australia). In fact
the very idea of using BASIC as the basis of a 4GL was regarded as a bit
ridiculous. I thought I was going to be using C++ if I wanted a job.

If you don't remain flexible in this fast-changing profession I feel
you're in danger of locking yourself into a shrinking box.

PS: I've used Pascal and VB has reminded a lot more of Pascal than the
old BASIC I remember.

Quote:
>There is also increasing use of Basic for scripting languages which makes
>it even more useful.
>I think if they would have made Delphi C-based it would have been a VB
>killer. As it is, however, I know very few programmers (who don't already
>know Pascal) who are even looking at it for possible development.
>Just my $.02 worth.

Fair enuf, due to the exchange rate I've had to give my Aus$0.03 worth ;^)

Regards

Duncan
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Duncan McCardle
 CRC for Tropical Pest Management    Telephone : +61 7 365 1859
 Gehrmann Laboratories               Facsimile : +61 7 365 1855
 The University of Queensland

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Mon, 01 Sep 1997 16:25:00 GMT  
 delphi - some problems
X-Newsreader: WinVN 0.91.4


says:

Quote:

[snip]
>> I think if they would have made Delphi C-based it would have been a
>VB
>> killer. As it is, however, I know very few programmers (who don't
>already
>> know Pascal) who are even looking at it for possible development.
>> Just my $.02 worth.

[snip]

A good language has a number of virtues which make programmers
productive. These include:-

1. a rich set of data structure primitives e.g dynamic arrays,
collections, etc.

2. Good flow control facilities, SELECT, DO.... LOOP etc.

3. Ability to extend the language by calling subroutines in other
languages.

4. Orthogonality of the language. i.e if it works here it also works
there.

5. Ease of maintenance i.e can you read code you wrote six months ago.

C fails miserably on most of these tests. The most serious flaws in C
(and by extension C++) was the decision of the authors to make the
language extremely cryptic. Although this resulted in a very small number
of reserved words relative to other languages, the result was to overload
metacharacters to the point of unreadability.

For example, the use of '*' to indicate pointers, and in C++, the
overloading of '&' to indicate references.

Metacharacters are a poor choice because although they are compact and
easily parsed, they do not map semantically within the human brain and
consequently C code is very difficult to read. Even though you may have
years of experience in C, you will find it slow to read. The brain has to
do a lot of pre-processing to translate the code.

The second serious flaw in C is the lack of orthogonality. The authors
made a classic blunder in the use of the '=' and '==' operators which
results in the most common C error; using a = b when you meant a == b.

It would have been quite different if the assignment operator had been
different e.g :=, because then you couldn't get mixed up so easily.

Other non-orthogonal issues in C include the peculiar syntactical
structure; for example:-

for (i=0;i<=10;i++)

which looks like a function call, but is not, and in which there are no
clues as to the meaning due to the lack of 'noise' words. Compare this
with

for i = 0 to 10 step 1

which while more verbose is instantly readable, even to a novice
programmer.

Another non-orthogonal issue is the fact that doing this

char a[4] = "abc"
char b[4] = "def"

a = b;

will certainly not copy characters from b to a. However, if a and b were
structures containing char strings, it *would*. This sort of behaviour
drives even experienced C programmers crazy.

Finally, C operates at such a low level that the data structures provided
are too weak for most programming projects. The lack of
dynamically-assigned strings, dynamic arrays etc. is a serious weakness
because these must be built with error-prone code which dynamically
allocates memory and releases it as required.

C maps well to embedded control programs, operating systems, device
drivers and the like where efficiency is important and the only other
choice is assembler. But for large programming projects in other spheres
e.g accounting etc. I believe the language is far too poorly designed.

Languages such as Pascal and BASIC are much easier to learn because they
are more readable, though this doesn't imply they don't have {*filter*} bits
too; consider:-

line(0,0)-(100,100)

which is really weird. To be orthogonal with the move method it ought to
be

form.line 0,0,100,100

but of course the earlier syntax dates from the days of TRS80 BASIC and
we're stuck with it.

As for C++, the designers were faced with supporting C as a subset of the
language. This exacerbated the metacharacter problem with a vengeance as
the 'language lawyers' had to find ways of squeezing in new features
without breaking C code. The classic example is the use of '&' characters
in references; in C this character is used to denote 'address of' but
because this is only legal on the RHS of an assignment, this operator can
be overloaded to mean a reference instead if used on the LHS. Very clever
but hardly readable.

Furthermore C++ does not provide much additional protection against
programmer oversight; for example, variables allocated with new are not
automatically deleted when they go out of scope.

I only know of one language where the clarity of design of the language
are matched by the power and flexibility of it; this is SmallTalk, in my
opinion a superior language to anything else; it is simple, yet powerful,
and yet still readable. A work of genius that all developers should
explore. As for BASIC - I like it a lot; and as for Pascal, well, I
haven't ever programmed in it BUT the other day I took 3,000 lines of
Pascal and had no trouble understanding what it did, how it did it, and
how to translate it to VB.

I could do the same with C but it took me months to learn the language. I
think Borland made the right choice though I am disappointed they didn't
choose SmallTalk - but compiled Pascal will definitely be more efficient,
of course.

That's *my* 10c worth. Not that 10c *is* worth much these days, of
course.



Tue, 02 Sep 1997 05:50:09 GMT  
 delphi - some problems
I recently picked up DELPHI and it looks like one hell of a package
for the buck.  By using Pascal vs C++ for the scripting language the
actual code is smaller and more readable.  As for Borlands decision
to use Pascal, I think it has quite a bit to do with the fact that
the generated code is nearly the same as object pascal, for which
Borland already had a compiler.

I am by no means a PASCAL programmer, however the modern labels of
PASCAL as used in Delphi and BASIC as used in VB are just that they
are labels.  The languages used in the products only somewhat
resemble PASCAL and BASIC.  If you begin to use these products and
or PowerBuilder, you'll notice that they have more in common than
the language label would lead you to believe.

In Delphi's defense the product appears solid, it has an excellent
programmer interface, it should be easy to distribute applications,
and a truly compiled app should run faster than the competition.

The only problems I have experienced with Delphi are in the manuals and
sample applications.  The manuals are barely adequate in providing
information, and have a cheap feel.  A programming environement should
have MANUALS for the language, script, or whatever.  A cupon to
purchase the language guide and component guide for $34 is included
in the box.  As for the sample apps, all are too simple to be of
great use, none use ini or parms, and a comm sample would have been
a welcome addition.

The only other DELPHI problem is Borland.  As a valued C++ registered
user, I have been for years and many upgrades, I received a special
$199 into offer for Delphi.  The next week I saw it for $179 at CompUSA.
A friend that had the same valued user offer called Borland and picked
up delphi for $149.  I went over to the local best buy and found it
for $129.  It pays to shop around.  Instead of insulting me with the
$199 offer, companies like Borland should send a discount cupon to their
valued customers to be used in the retail purcase of the software.  This
will promote dealer sales, create instant demand for your new product with
your existing customer base, and keep everyone happy.

Good luck
ttfn

Greg G,



Tue, 02 Sep 1997 12:46:55 GMT  
 delphi - some problems
Hi Andrew.

I agreed with most of your points. In fact I've been saying a lot of the
same things for a long time. I hate the way C was made so popular that
every programmer thought it was the Holy Grail. In my view, writers of C
compilers have made far too many sales. C compilers should be expensive
professional tools, not mass-market shrinkwrapped items.

Still my pedantic little soul causes me to pick fault with one statement...

[In comp.lang.basic.visual.misc Andrew Mayo writes]

[snip]

Quote:
>Another non-orthogonal issue is the fact that doing this
>char a[4] = "abc"
>char b[4] = "def"
>a = b;
>will certainly not copy characters from b to a. However, if a and b were
>structures containing char strings, it *would*. This sort of behaviour
>drives even experienced C programmers crazy.

It's even driven you crazy I suppose <g>

First, the above wouldn't compile (apart from the missing semicolons)
because you can't assign an array like that, so at least it's not a
mistake that would carry past the compile phase. More importantly
though, it wouldn't work for structures either, so it's not an issue of
orthogonality. To copy structures in C you use memcpy. I know, great
syntax, but that's how it works.

Quote:
>Finally, C operates at such a low level that the data structures provided
>are too weak for most programming projects. The lack of
>dynamically-assigned strings, dynamic arrays etc. is a serious weakness
>because these must be built with error-prone code which dynamically
>allocates memory and releases it as required.

Very true. An applications programmer certainly should not be using C or
C++. C++ was an attempt to turn C into an applications language, and it
failed dismally, because it's still C with a bunch of fruit salad on top.

For a systems programmer though, it sure beats assembly language, and
it's almost as fast at runtime. The syntax may be ugly, but it's the only
game in town. A real C programmer wouldn't want to make a little slip and
find that his programming is moving huge slabs of memory around when it
doesn't need to after all. He's much better off doing a little smoke and
mirrors with pointers. All of which is really just agreeing with your
next point...

Quote:
>C maps well to embedded control programs, operating systems, device
>drivers and the like where efficiency is important and the only other
>choice is assembler. But for large programming projects in other spheres
>e.g accounting etc. I believe the language is far too poorly designed.

Yes. Yes. YES!

All very good points. One of these days I'm going to get around to
working with Smalltalk. I abominate C++, and I love C warts and all.

Keep up the good work.

Luke

--
Luke Webber

* Note: The opinions expressed by Luke Webber are in no way supported *
*       by his employers, Luke Webber Consulting Services             *



Tue, 02 Sep 1997 19:35:47 GMT  
 delphi - some problems

Quote:
>First, the above wouldn't compile (apart from the missing semicolons)
>because you can't assign an array like that, so at least it's not a
>mistake that would carry past the compile phase. More importantly
>though, it wouldn't work for structures either, so it's not an issue of
>orthogonality. To copy structures in C you use memcpy. I know, great
>syntax, but that's how it works.

        No doubt I`m mistaken but I thought one could assign one variable
to another of the same type even if this is a compound type such as a
structure:

        mystruct a;
        mystruct b;

        a = b; /* copy contents of structure b to structure a */

        Never could in old C but I thought ANSI C was much improved in this
area.  I'll be quiet and go back to VB ...

        David.

---
I was gratified to be able to answer promptly, and I did.  I said I didn't know.
                                                Mark Twain.



Tue, 02 Sep 1997 21:35:42 GMT  
 
 [ 18 post ]  Go to page: [1] [2]

 Relevant Pages 

1. delphi - some problems

2. VB and Delphi OCX problems.

3. Borland brings Delphi tools to C++ (Ebony/Delphi++)

4. NEW! VB-Delphi, C++Delphi References

5. Delphi Newsgroup, Delphi & Multimedia

6. problem with delphi and access

7. Problems with Delphi 2 and OLE - MSWord

8. problem with class smtp from Delphi

9. VB or Delphi which is the better tool to develop with Visual Basic or Delphi?

10. Delphi Vs Visual Basic

11. Delphi alike dbgrid

12. Using DAO 3/3.5 via OLE with Delphi 3.01

 

 
Powered by phpBB® Forum Software