Board index » delphi » Delphi vs. Visual Basic, Microsoft downplays delphi

Delphi vs. Visual Basic, Microsoft downplays delphi

Quote
m...@neosoft.com (md) wrote:
>Talked to a microsoft rep today about hooking delphi
>to a system using their drivers and developing drivers
>for my delphi application in windows. The rep there
>asked about my reasons for choosing delphi and talked
>about the virtues of using microsoft's visual basic
>instead.
>    The comments were:
>Will Borland be around to support delphi for the long
>run or will the program be sold and wind up an unsupported
>orphan?

Hmm. This is (pardon me) un{*word*62}erated porcine excrement. It may come as a
disappointment to some (especially that Microsoft person) that Borland is
not going to dissolve into the ether any time soon. On the contrary. After
a painful restructuring and a realignment of our priorities and charter,
Borland is coming back strong. Borland is again profitable, earnings are
up, and sales brisk. Our stock has been upgraded a couple of levels by
multiple Wall Street stock analysis firms. But no one need take my word for
this. It can be verified by outside sources.

Sell off Delphi?! This is a possibility (enter Rod Serling), but would be
suicidal for Borland. Delphi is still under development (the 32-bit
version) and future plans are even now being made. No, selling off Delphi,
making it an orphan, would be very contrary to the best interests of
Borland. (Did I sense some sour grapes in his/her assessment?)

Also, Borland can rely on the quality of the product rather than spreading
false or misleading information about its competitors to sell its products.

Quote
>Do you really expect to be able to develop better software
>using delphi?

Delphi is good if you want to do as much as possible in the same
development environment, and with a minimum of work arounds and reliance on
outside DLLs made in some other development package to cover functionality
not built into other products.

Quote
>He mentioned the program space taken up by visual basic applications
>as being quite a bit larger than C++ programs but would not contrast
>the size with that of delphi programs.

The size of executable files created with Delphi will generally be larger
than those created in C++. But then, you do not need to write two pages of
code just to create a window with "Hello world" printed in it, either. I
would go head to head with any C++ programmer in a race to create this
window.

Delphi executables are larger because of inclusion of the libraries that
automate processes, create objects, and in general make applicationb
development easier. But there is a ceiling beyond which the increase in
size tapers off dramatically. Take the base size of an EXE with its
included libraries, and adding your own code will not increase that size
very much.

Quote
>He mentioned that microsoft had a large amount of support information
>available for hooks between visual basic and windows application
>programming interface packages. He alluded to the lack of a similar
>connection support structure for delphi.

The Windows API is Windows-specific, not Windows application-specific, so
you will not find an all-encompassing guide to using the API in Delphi.
What you will find is an entire help file -- WINAPI.HLP -- devoted to the
syntax (and some usage) of the API functions, including information on how
Delphi/Pascal data types are used with the various API functions. If you
need extensive explanations of using a given API function, I would suggest
either getting a good third-party book on the subject or taking advantage
of Microsoft's resources. They are, after all, the ones who created the
Windows API.

As far as using API functions in Delphi, it is not very difficult. No
special considerations need be made (aside from those required by specific
functions). You can call most API functions from within a Delphi
application just as easily as Delphi functions. Some do require a little
work or preparation.

Quote
>Finally he suggested that development time may be shorter for visual
>basic in many applications.

In "many" maybe. The greater majority, though ... ? Call that Microsoft
person back sometime and ask him/her how Visual Basic fared in the
application showdown competition at SD East. (Hint: VB had to pull out of
the competition, Delphi came in second.)

Quote
>He also stated that the delphi programs may run 2 or 3% faster than
>visual basic programs but he did not contrast that with C++.

Other have (and hopefully more will) commented on this. I think the
opinions of users outside of Borland will be more convincing that anything
I can say.

Quote
>I question much of what I was told.

Borland has a standing 90-day, no-questions-asked money-back guarantee. If
Microsoft has a similar arrangement, I would suggest getting both products.
Try them both. Put them through your own paces. See for yourself which is
bestest, fastest, completest. Then return the other one.

[...]

**************************************************************************
Steve Koterski
Product Group Manager
Delphi Technical Support
Borland International, Inc.

 

Re:Delphi vs. Visual Basic, Microsoft downplays delphi


I think that the MS rep is not telling the truth. Ignore his comments
completely, they are too biased for reasonable consideration.

VB is probably better for OLE client/server development (VB4 anyway),
but Delphi is infinitely better for any other kind of Windows
applications.

If you want to mess around really deeply with the bus and system
memory, then use MS VC++, Delphi is not really suited to low-level
programming (although it can do it!), and your learning curve would be
shorter.

On 16 Oct 1995 16:40:28 GMT, m...@neosoft.com (md) wrote:

Quote

>Talked to a microsoft rep today about hooking delphi
>to a system using their drivers and developing drivers
>for my delphi application in windows. The rep there
>asked about my reasons for choosing delphi and talked
>about the virtues of using microsoft's visual basic
>instead.
>    The comments were:
>Will Borland be around to support delphi for the long
>run or will the program be sold and wind up an unsupported
>orphan?

>Do you really expect to be able to develop better software
>using delphi?

>He mentioned the program space taken up by visual basic applications
>as being quite a bit larger than C++ programs but would not contrast
>the size with that of delphi programs.

>He mentioned that microsoft had a large amount of support information
>available for hooks between visual basic and windows application
>programming interface packages. He alluded to the lack of a similar
>connection support structure for delphi.

>Finally he suggested that development time may be shorter for visual
>basic in many applications.

>He also stated that the delphi programs may run 2 or 3% faster than
>visual basic programs but he did not contrast that with C++.

>I question much of what I was told.

>I am particularly interested in programming which will allow me to
>build boards for plugging into the bus of a pc and take advantage of
>interupts and the user reserver memory mapped addresses between
>locations CD000H and CFFFFH.

>If you have any comments on this matter I would greatly appreciate
>hearing from you. I expect to purchase development software and
>embark on several years of development. I do not want to make a
>choice which will require me to restart all my effort after a
>couple of years. I am also concerned with the learning curve and
>general program development time because although I've done a
>lot of programming on imbedded applications, none of it has been
>PC based C++ or visual basic or delphi. Whichever way I go I have
>to make tradeoffs.

>Responses posted here or sent through email would both be welcome.

>Thanks in advance,
>Mike

---------------------------------
Casey Charlton
ca...@larouss.demon.co.uk

Re:Delphi vs. Visual Basic, Microsoft downplays delphi


Quote
m...@neosoft.com (md) wrote:

>Talked to a microsoft rep today about hooking delphi
>to a system using their drivers and developing drivers
>for my delphi application in windows. The rep there
>asked about my reasons for choosing delphi and talked
>about the virtues of using microsoft's visual basic
>instead.
>    The comments were:
>Will Borland be around to support delphi for the long
>run or will the program be sold and wind up an unsupported
>orphan?

>Do you really expect to be able to develop better software
>using delphi?

>He mentioned the program space taken up by visual basic applications
>as being quite a bit larger than C++ programs but would not contrast
>the size with that of delphi programs.

>He mentioned that microsoft had a large amount of support information
>available for hooks between visual basic and windows application
>programming interface packages. He alluded to the lack of a similar
>connection support structure for delphi.

>Finally he suggested that development time may be shorter for visual
>basic in many applications.

>He also stated that the delphi programs may run 2 or 3% faster than
>visual basic programs but he did not contrast that with C++.

>I question much of what I was told.

>I am particularly interested in programming which will allow me to
>build boards for plugging into the bus of a pc and take advantage of
>interupts and the user reserver memory mapped addresses between
>locations CD000H and CFFFFH.

>If you have any comments on this matter I would greatly appreciate
>hearing from you. I expect to purchase development software and
>embark on several years of development. I do not want to make a
>choice which will require me to restart all my effort after a
>couple of years. I am also concerned with the learning curve and
>general program development time because although I've done a
>lot of programming on imbedded applications, none of it has been
>PC based C++ or visual basic or delphi. Whichever way I go I have
>to make tradeoffs.

>Responses posted here or sent through email would both be welcome.

As to the EXE size issue, here is my answer:

Program ExitWin;
uses WinProcs;

begin
  ExitWindowsExec('', '');
end.

will create a 2816 byte executable with the Delphi compiler.  
Then, if you run W8LOSS.EXE, it will shrink it down to 2463
bytes!!!  That is TINY for a native windows app!

Note:  This program will exit and restart windows.

Lloyd <Borland>

Re:Delphi vs. Visual Basic, Microsoft downplays delphi


Quote
md (m...@neosoft.com) wrote:

: Talked to a microsoft rep today about hooking delphi
: to a system using their drivers and developing drivers
: for my delphi application in windows. The rep there
: asked about my reasons for choosing delphi and talked
: about the virtues of using microsoft's visual basic
: instead.

: The comments were:
: Will Borland be around to support delphi for the long
: run or will the program be sold and wind up an unsupported
: orphan?

This is a legitimate question but I think the answer is that
Borland won't sell a successful product at this point (not to
mention that it will be "supported" by the members of groups
like this).

: Do you really expect to be able to develop better software
: using delphi?

Oh, yes.  I've got a friend who developed a "real-world" inventory
application in Access Basic 2.0 and from what I saw of the code
Delphi is a much better choice for maintainability (sp?).  Then he
decided to buy Visual Basic 4.0 because Access Basic couldn't
generate applications separate from the database and Visual Basic
3.0 couldn't access Access 2.0 databases.  

: He mentioned the program space taken up by visual basic applications
: as being quite a bit larger than C++ programs but would not contrast
: the size with that of delphi programs.

Delphi program size falls somewhere in between C++ and VB for comparable
applications.  Delphi can be used to generate really small applications
and DLL's (VB cannot).

: He mentioned that microsoft had a large amount of support information
: available for hooks between visual basic and windows application
: programming interface packages. He alluded to the lack of a similar
: connection support structure for delphi.

Unless she/he was talking about interfacing to Microsoft Office products
or undocumented features of windows, this is not true.  It is very
easy to build an "interface" unit to any DLL in Delphi.

: Finally he suggested that development time may be shorter for visual
: basic in many applications.

Without qualification, this is a meaningless statement.  The most
time-consuming part of programming under VB or AcessBasic was making
sure that error conditions were handled properly.  This is extremely
painless in Delphi thanks to the integrated exception handling.  So for
a "resilient" application, I don't think that a VB app would take any
less time to develop.

: He also stated that the delphi programs may run 2 or 3% faster than
: visual basic programs but he did not contrast that with C++.

Again, this is a meaningless statement.  Some Delphi programs will run
10 to 30 TIMES faster than a VB program.  Some Delphi programs cannot
be written in VB.  VB may run some programs faster than a Delphi
program (my guess would be programs which access an Access 2.0 database
directly - Delphi has to go through the ODBC interface).

: I question much of what I was told.

Glad to hear it !!!  Sounds like the MS FUD machine is worried about
Delphi.  That bodes well for Delphi.

: I am particularly interested in programming which will allow me to
: build boards for plugging into the bus of a pc and take advantage of
: interupts and the user reserver memory mapped addresses between
: locations CD000H and CFFFFH.

: If you have any comments on this matter I would greatly appreciate
: hearing from you. I expect to purchase development software and
: embark on several years of development. I do not want to make a
: choice which will require me to restart all my effort after a
: couple of years. I am also concerned with the learning curve and
: general program development time because although I've done a
: lot of programming on imbedded applications, none of it has been
: PC based C++ or visual basic or delphi. Whichever way I go I have
: to make tradeoffs.

As much as I like Delphi, I would guess that you are going to have
to write windows device drivers (aka VxD's).  This cannot be done in
Delphi.  I think that you will need a C/C++ compiler for at least
that part of your project.  Also, I feel that C/C++ would be a better
choice for a project of the size and expected lifetime that you are
comtemplating (flame-proof undies ON).

For the database and user-interface portion of your proposed project,
Delphi would be a great choice.  I am currently working on a Delphi
program which interfaces to a device attached to a parallel port.  The
low-level code is written in C and the UI calls the C functions to
get work done.  This allows existing code to be used but also allows
rapid user interface rework as requirements change (i.e. when the
marketing people come back from lunch :-)

Erik Turner
etur...@ccd.harris.com

Re:Delphi vs. Visual Basic, Microsoft downplays delphi


In article <814006306.17...@larouss.demon.co.uk>,
   ca...@larouss.demon.co.uk (Casey Charlton) wrote:

Quote
>Path: news.service.uci.edu!usc!howland.reston.ans.net!EU.net!uknet!dispatch.news.demon.net!demon!larouss.demon.co.uk
>From: ca...@larouss.demon.co.uk (Casey Charlton)
>Newsgroups: comp.lang.pascal.delphi.misc
>Subject: Re: Delphi vs. Visual Basic, Microsoft downplays delphi
>Date: Wed, 18 Oct 1995 08:54:06 GMT
>Lines: 37
>Message-ID: <814006306.17...@larouss.demon.co.uk>
>References: <45u1ts$...@uuneo.neosoft.com> <813918157.13...@larouss.demon.co.uk> <pacsoftDGM0pL....@netcom.com>
>NNTP-Posting-Host: larouss.demon.co.uk
>X-NNTP-Posting-Host: larouss.demon.co.uk
>Status: N

>On Tue, 17 Oct 1995 20:24:57 GMT, pacs...@netcom.com (Wilhelm
>Sarasalo) wrote:

>>Casey Charlton (ca...@larouss.demon.co.uk) wrote:
>>[SNIP]
>>: If you want to mess around really deeply with the bus and system
>>: memory, then use MS VC++, Delphi is not really suited to low-level
>>                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>: programming (although it can do it!), and your learning curve would be
>>  ^^^^^^^^^^^
>>: shorter.

>>Please elaborate.

>>Thanx,

>>Wilhelm

>Although you can access low-level functions in Delphi, with complete
>access to the Windows API and easy interfacing to DLL's,  Delphi is
>obviously aimed at medium to high level applications programming.

>C++ has a wealth of functions already written and available to access
>the nitty-gritty parts of your system (and for example is the only way
>to write VXD's), so it seems a bit pointless to re-invent the wheel,
>and do all the hard work in Delphi.

>It is also generally true that C++ die-hards LOVE to play around with
>low-level system functions, and take great pleasure in bypassing
>Windows where possible. Us Delphi programmers prefer to take the easy
>route, so you're likely to get more help in a C++ forum than here.

>---------------------------------
>Casey Charlton
>ca...@larouss.demon.co.uk

        Dear Mike,

I strongly disagree with Mr. Charlton's opinion regarding the
pre-supposed superiority of C/C++ over Delphi.

First of all, C++ is not the only way to write VxDs. VxDs are
usually written in assembler. It is possible to write VxDs in
C++, but with the help of special development tools (DDK or
VDTools for instance).

You can call VxD services from within your Delphi program using
a bit of in-line assembly code to call Int 2F and pass data to the
registers (done that, it's a cinch). By the way, you would do same
thing if you were using a product like VC++ 1.5.

You can access ports in Delphi (see Port[xx], for instance), or
"peek" and "poke" at various memory addresses. I may be mistaken,
but port instructions are missing in VC++ 1.5. I am under the
impression that you have to use assembly language, but I could
be wrong.

You need to use a DLL in Visual Basic, since the equivalents of
Peek and Poke do not exist in VB (no mention, of course, of an
in-line assembler). You may incur also a small performance penalty,
since, from your VB program, you have to call a function in another
module, but I don't know if this delay is significant compared to
a port access from a Ring3 program (which takes, if my memory doesn't
fail me, something like a whooping 30 cycles!).

If you need to access hardware, I would recommend you to go to
Delphi directly. This will allow you to program all the pretty
user interface, but also the code dealing with hardware within
the same development environment. With VB, you may feel good
the first days after slapping a slick-looking user interface
(you can do that in Delphi, too). But I can ensure you that you
will hit brick walls after brick walls very soon with VB.

If you are interested with hardware issues in Windows, I would
suggest you to read first the book by K. Hazzah (see the FAQ
posted monthly in comp.os.ms-windows.programmer.vxd for the
exact reference).

        Best regards (and good luck)

Quoc Thang NGUYEN
Laboratory of Cellular and
Molecular Neurobiology
Dept. of Psychobiology
University of California, Irvine
Irvine, CA92717 USA
Ph: (714) 824-4730
Fx: (714) 824-3522

Re:Delphi vs. Visual Basic, Microsoft downplays delphi


Quote
>>Talked to a microsoft rep today about hooking delphi
>>to a system using their drivers and developing drivers
>>for my delphi application in windows. The rep there
>>asked about my reasons for choosing delphi and talked
>>about the virtues of using microsoft's visual basic
>>instead.
>>        The comments were:
>>Will Borland be around to support delphi for the long
>>run or will the program be sold and wind up an unsupported
>>orphan?

If Borland isn't 'around', who will be to provide some semblance
of competition to Microsloth.  The situation is VERY BAD now,
with all the power being thrown around by M$.  Imagine a world
without even one David to throw pebbles at the software Giant.

When AT&T had a total monopoly, at least the government had
some control over prices.  Microsoft has a virtual monopoly and
no control.  We're all in deep s*** and don't realize it yet.

Re:Delphi vs. Visual Basic, Microsoft downplays delphi


Quote
Lloyd (llinkla...@wpo.borland.com) wrote:

Lloyd, you could have answered his questions!

Quote
: m...@neosoft.com (md) wrote:

: >
: >
: >Talked to a microsoft rep today about hooking delphi
: >to a system using their drivers and developing drivers
: >for my delphi application in windows. The rep there
: >asked about my reasons for choosing delphi and talked
: >about the virtues of using microsoft's visual basic
: >instead.
: >  The comments were:
: >Will Borland be around to support delphi for the long
: >run or will the program be sold and wind up an unsupported
: >orphan?

Only time will tell on this, Borland's stock price is rising,
they are refocusing, they sold some 125,000 copies of Delphi
at last count, I personally think that Borland will be around
for a long time. The only possibility is that someone bigger
comes along and eats then, and considering what a load of
rubbish VB is, that might be Microsoft!

: >
: >Do you really expect to be able to develop better software
: >using delphi?

From someone who has developed inboth, majorly silly question.
The answer is YES YES YES! Developing in Delphi is so much faster,
better, more satisfying, etc than in VB. Delphi uses a proper
language (Object Pascal), VB, wel....

: >He mentioned the program space taken up by visual basic applications
: >as being quite a bit larger than C++ programs but would not contrast
: >the size with that of delphi programs.

VB footprint size is considerably larger than C++ but it uses
interpreted P-Code, which means your 'exe' is in fact not an exe
but a whole load of codes that require a DLL (which is around 700k)
to run. Most Delphi apps start at around 200k (they have quite a lot
of functionality in them) but the difference is in your libraries. Visual
C++ requires the MFC DLLs which means that although the size of your
C++ app _seems_ smaller, its actual needs are being hidden by the
requirement of the MFC dlls. Considering the DLL interface is functional
(and not class/object based) you loose your object functionality when
you have to provide function based hooks. Any app will increase with
libraries, you have to consider how to want to develop - easy = bigger
files (vbrun, mfc dlls, delphi libs included in exe)- harder (no
functionality enhancements) = smaller exes.

: >He mentioned that microsoft had a large amount of support information
: >available for hooks between visual basic and windows application
: >programming interface packages. He alluded to the lack of a similar
: >connection support structure for delphi.

This is quite silly for two reasons
1) VB and Delphi are just programming languages. Even if Microsoft
do provide more info for VB (it is a bit of a silly statement for him
to make actually, i mean, they aren't going to provide info for other
products are they?) you can easily use that info in any other language
If you are looking at development tools then he is fooling you - VBXs
don't work with VB4 so you have lost all of that installed base. VBXs
do work with Delphi, but only V1 VBXs - just like Visual C++. VB4 can't
create OCX's (which are the new '95/32bit standard), Delphi-32 can.
Why? because VB is interpreted and Delphi is not.

: >
: >Finally he suggested that development time may be shorter for visual
: >basic in many applications.

What he means is that debugging is faster, because VB is interpreted.
Development? I would say certainly not - in VB most of your time is
spent on banging your head against brick walls and having to go into
C++ to try and write the componentry required to achive your application.
Delphi is a language that provides almost all of the functionality that
C++ does (operator overloading and templates are the most obvious
exclusions), VB4 doesn't even have a workable object model!

: >He also stated that the delphi programs may run 2 or 3% faster than
: >visual basic programs but he did not contrast that with C++.

Delphi programs using the same libs run at the same effective speed
as C++, and in some cases faster depending on the optimisations of
your compiler. Part of the documentation for Delphi-32 shows comparisons
between PowerBuilder 3.0, VB3, Delphi-16 and Delphi-32. In all cases,
Delphi run 4-5 times the speed of the VB equivalent (VB4 is supposed to
be even slower). That is 400-500% faster. Delphi-32 ran even faster
than that - the figures for sieve went something like VB=14, Del-16=56,
Del-32=150. In many cases, Delphi was over 800 times faster than PowerBuilder.

Your rep is trying to do damage control...

--
"...I'll leave my mind beneath the mat, so you can let yourself in,
if you can stand the mess then stay, but i'm not entertaining..."

Re:Delphi vs. Visual Basic, Microsoft downplays delphi


On:       17.10.95
wrote:    Lloyd  - llinkla...@wpo.borland.com

Quote
> As to the EXE size issue, here is my answer:

> Program ExitWin;
> uses WinProcs;

> begin
>   ExitWindowsExec('', '');
> end.

> will create a 2816 byte executable with the Delphi compiler.
> Then, if you run W8LOSS.EXE, it will shrink it down to 2463
> bytes!!!  That is TINY for a native windows app!

You are joking! With BP 7.0, you get it down to 1536 bytes!
Delphi makes it nearly twice as big as needed!

Frank

Re:Delphi vs. Visual Basic, Microsoft downplays delphi


Quote
>Will Borland be around to support delphi for the long
>run or will the program be sold and wind up an unsupported
>orphan?

     There exists a slight chance, but Delphi is too good to die. Someone
would likely buy it.

Quote
>Do you really expect to be able to develop better software
>using delphi?

     Yes Yes Yes Yes Yes Yes Yes.  (Are they screening these people at MS for
drug use?)

Quote
>He mentioned the program space taken up by visual basic applications
>as being quite a bit larger than C++ programs but would not contrast
>the size with that of delphi programs.

     Heheheh. Have you seen the memory requirements for VB4? WELL over 2 Megs
of runtime, unless it is a skeleton, and then it still uses 1 Meg.

Quote
>He mentioned that microsoft had a large amount of support information
>available for hooks between visual basic and windows application
>programming interface packages. He alluded to the lack of a similar
>connection support structure for delphi.

     Get them and translate.

Quote
>Finally he suggested that development time may be shorter for visual
>basic in many applications.

     What a joke!  Only if you cannot comprehend the superior concept of REAL
OOP.  Not that quasi OOP {*word*99}.

Quote
>He also stated that the delphi programs may run 2 or 3% faster than
>visual basic programs but he did not contrast that with C++.

     2-3%??????? Try 200-300%. (and more in many cases)

Quote
>I question much of what I was told.

     I would question ALL of it.

Quote
>I am particularly interested in programming which will allow me to
>build boards for plugging into the bus of a pc and take advantage of
>interupts and the user reserver memory mapped addresses between
>locations CD000H and CFFFFH.

     Don't even consider VB for this.  MS should have told you they did not
design it for that.  Usually they push VC++ and explicitly tell  you not to
use VB for these things.

Quote
>couple of years. I am also concerned with the learning curve and
>general program development time because although I've done a
>lot of programming on imbedded applications, none of it has been
>PC based C++ or visual basic or delphi. Whichever way I go I have
>to make tradeoffs.

     Delphi would be my choice. C++ has a STEEP learning curve, and VB won't
even come close to doing what you need.

--------------------------------------------------------
|Chad Z. Hower - P...@pobox.com - http://pobox.com/~pbe |
|Independent Consultant as Phoenix Business Enterprises|
|          &                                           |
|Senior Analyst Programmer - Seltmann, Cobb & Bryant   |
--------------------------------------------------------
_
This isn't the moon? This is PA? What are all those holes?

Quote
>> SQUID - The Ultimate Usenet Utility #BLYGJOMK

Special Compile: 1.032/1.031B (Beta)

Re:Delphi vs. Visual Basic, Microsoft downplays delphi


As a user who has long been a suppoter of Borland
I have used and  use Dbase Paradox for DOS and Windows
and Borland C++  I was glad to see Delphi and have all
but adopted it as my primary development platform.

The big difference to me has come in support.  I dont
mind not having a toll fre number or paying for support
after a time period (but from the word go is wrong).  
What I do find Microsoft better at is answering
Questions sent via Email and posted on Boards in a more
timely manner.  I have been unale to get an answer from
anyone at Borland regarding Some font
problems in Win 95 with Delphi.  The answer seems like
it would be simple.  This problem has left me unable to
use DElphi and forced me to turn projects to VBasic .
I am considering whether to move to  VBasic 4.0 or go to
32 bit Delphi.  If Borland can not help me I will be
forvced to stick with a company that at least answers
its mail.

the problem I am having is that the font used by Delphi
is apperently gone bad on my move to Win 95 I cannot
seen to find out what font it is or hoew to fix it.  As
a result all canned Dialogs and other boxes (preferences
etc.) show a wingDing Font.  PLEASE help I really would
like to get projects moving in Delphi agian.  Thanks

Re:Delphi vs. Visual Basic, Microsoft downplays delphi


Quote
Shannon Hanson wrote:
> the problem I am having is that the font used by Delphi
> is apperently gone bad on my move to Win 95 I cannot
> seen to find out what font it is or hoew to fix it.  As
> a result all canned Dialogs and other boxes (preferences
> etc.) show a wingDing Font.  PLEASE help I really would
> like to get projects moving in Delphi agian.  Thanks

Shannon,

I had the exact same problem. The only solution for me
was to figure out exactly which font it was, and remove
it from my hard drive. For some reason I couldn't remove
from the Fonts control panel. I had to remove the file
'by hand'.

I'm sorry but I dont' recall the name of the font. I think
it started with an 'M', though.

It certainly was a royal pain, though.

--

Jonathan W. Hendry      Steel Driving Software, Inc.
Delphi and NeXTSTEP consulting and software development.
Cincinnati, Ohio

Re:Delphi vs. Visual Basic, Microsoft downplays delphi


Quote
Shannon Hanson wrote:
> the problem I am having is that the font used by Delphi
> is apperently gone bad on my move to Win 95 I cannot
> seen to find out what font it is or hoew to fix it.  As
> a result all canned Dialogs and other boxes (preferences
> etc.) show a wingDing Font.  PLEASE help I really would
> like to get projects moving in Delphi agian.  Thanks

Shannon,

I had the exact same problem. The only solution for me
was to figure out exactly which font it was, and remove
it from my hard drive. For some reason I couldn't remove
from the Fonts control panel. I had to remove the file
'by hand'.

I'm sorry but I dont' recall the name of the font. I think
it started with an 'M', though.

It certainly was a royal pain, though.

--

Jonathan W. Hendry      Steel Driving Software, Inc.
Delphi and NeXTSTEP consulting and software development.
Cincinnati, Ohio

Re:Delphi vs. Visual Basic, Microsoft downplays delphi


Sorry for the double-posts. It's either Netscape or Netcom,
but one of em was saying the postings had failed.

- Jon
--

Jonathan W. Hendry      Steel Driving Software, Inc.
Delphi and NeXTSTEP consulting and software development.
Cincinnati, Ohio

Re:Delphi vs. Visual Basic, Microsoft downplays delphi


On Oct 16, 1995 23:01:05 in article <Re: Delphi vs. Visual Basic, Microsoft
downplays delphi>, 'koter...@borland.com (Steve Koterski)' wrote:

Quote
>m...@neosoft.com (md) wrote:

[...deleted...]

Quote
>>Finally he suggested that development time may be shorter for visual  
>>basic in many applications.

>In "many" maybe. The greater majority, though ... ? Call that Microsoft
>person back sometime and ask him/her how Visual Basic fared in the
>application showdown competition at SD East. (Hint: VB had to pull out of
>the competition, Delphi came in second.)

I was at SD East on Tuesday, and missed the showdown.
Would you post some details of the competition?

--
Grace + Peace
Peter N Roth
Engineering Objects International      rot...@usa.pipeline.com
Engineering and Scientific Software: Delphi    C++    f77 --> C++
On-Site Andragogy for Beginning and Experienced Programmers

Re:Delphi vs. Visual Basic, Microsoft downplays delphi


Quote
Shannon Hanson <proto...@netrix.net> wrote:

[...]

Quote
>the problem I am having is that the font used by Delphi
>is apperently gone bad on my move to Win 95 I cannot
>seen to find out what font it is or hoew to fix it.  As
>a result all canned Dialogs and other boxes (preferences
>etc.) show a wingDing Font.  PLEASE help I really would
>like to get projects moving in Delphi agian.  Thanks

For the benefit of those following this sub-thread, the solution to this
problem was to remove a font called MonoType from access by Windows 95.
This font is added by Ami Pro. Removing this font from availability allows
Delphi to function.

**************************************************************************
Steve Koterski
Product Group Manager
Delphi Technical Support
Borland International, Inc.

Go to page: [1] [2]

Other Threads