Prev: VB6 Data missing when writing to a text file.
Next: Run Time Error 3265: Item cannot be found in the collection
From: David Kerber on 21 Jan 2010 09:35
In article <u41gl5hrqjfp2le4dha1jno9koodrkengk(a)4ax.com>,
ttoews(a)telusplanet.net says...
>
> "Ralph" <nt_consulting64(a)yahoo.com> wrote:
>
> >Other development platforms ARE exactly the same - including those created
> >by C/C++. The difference is VC++ provides static libraries or optional
> >external runtime DLLs. MS could have provided static libraries for VB but
> >they didn't.
>
> Ah, ok. I've seen the msvcrt.dll file. I hadn't realized what it
> was.
>
> Thanks for the explanation.
>
> The above all said Delphi does package everything up into one exe. Or
> so my understanding goes.

It can do so, but does not by default; it's a build option.

D

From: Ralph on 21 Jan 2010 10:20
Tony Toews [MVP] wrote:
>
> The above all said Delphi does package everything up into one exe. Or
> so my understanding goes.
>

OT:

You seem to be fishing around for a replacement for VB. (And what VBer isn't
these days? <g>)

Assuming your basic goal is a development platform to create shrink-wrapped
ancillary utilities for Office products, with some guarantee they will be
supported with future versions of Windows, IMHO, you have only three
choices.

1) Bite the bullet and go dotNet.
This gives the highest guarantee of future O/S support, but you'll have to
manage the shrink-wrap with shrouding, and there is still a bit of
disconnect between ActiveX (and Automation) and Interop. (Office still
speaks better "VBA" than "VSTO" <g>)

I expect it to get better, but then I've been 'expecting' since 2003. That's
a long time to be in labor.

[A pure unsubstantiated theory - MS is waiting for 64-bit Office.]

2) Go back to a C/C++ platform.
There is essentially nothing you can't do with 'C', given enough time. <g>

3) Go with Delphi.
Slightly less guarantee of future support simply because Delphi is a
competing vendor and simply because Borland itself is a tad shaky. (There
were still questions last year if there would ever be a 64-bit version.)
The platform is complete. It rivals any of the Microsoft platforms in terms
of tools and options, and is superior to any of the alternative "BASICs". It
has devoted users. You'll find much the same quality of support you get
here.

-ralph


From: Mike B on 21 Jan 2010 10:36

"Ralph" <nt_consulting64(a)yahoo.com> wrote in message
news:OFK8D3qmKHA.760(a)TK2MSFTNGP02.phx.gbl...
> Tony Toews [MVP] wrote:
>>
>> The above all said Delphi does package everything up into one exe. Or
>> so my understanding goes.
>>
>
> OT:
>
> You seem to be fishing around for a replacement for VB. (And what VBer
> isn't
> these days? <g>)
>
> Assuming your basic goal is a development platform to create
> shrink-wrapped
> ancillary utilities for Office products, with some guarantee they will be
> supported with future versions of Windows, IMHO, you have only three
> choices.
>
> 1) Bite the bullet and go dotNet.
> This gives the highest guarantee of future O/S support, but you'll have to
> manage the shrink-wrap with shrouding, and there is still a bit of
> disconnect between ActiveX (and Automation) and Interop. (Office still
> speaks better "VBA" than "VSTO" <g>)
>
> I expect it to get better, but then I've been 'expecting' since 2003.
> That's
> a long time to be in labor.
>
> [A pure unsubstantiated theory - MS is waiting for 64-bit Office.]
>
> 2) Go back to a C/C++ platform.
> There is essentially nothing you can't do with 'C', given enough time. <g>
>
> 3) Go with Delphi.
> Slightly less guarantee of future support simply because Delphi is a
> competing vendor and simply because Borland itself is a tad shaky. (There

No Borland. Embarcadero is the current owner.
http://www.embarcadero.com/

There is a substantial footprint of users worldwide.

> were still questions last year if there would ever be a 64-bit version.)
> The platform is complete. It rivals any of the Microsoft platforms in
> terms
> of tools and options, and is superior to any of the alternative "BASICs".
> It
> has devoted users. You'll find much the same quality of support you get
> here.
>
> -ralph
>
>


From: Tony Toews [MVP] on 21 Jan 2010 11:27
"Ralph" <nt_consulting64(a)yahoo.com> wrote:

>You seem to be fishing around for a replacement for VB. (And what VBer isn't
>these days? <g>)

Yes, that's in the back of my mind.

>Assuming your basic goal is a development platform to create shrink-wrapped
>ancillary utilities for Office products, with some guarantee they will be
>supported with future versions of Windows, IMHO, you have only three
>choices.

Not quite. My usage of VB6 is for a popular stand alone utility which
is used with MS Access but does not in any way depend on Office or
Access to be installed.

>1) Bite the bullet and go dotNet.

To quote my website. "The Auto FE Updater is a drag and drop
deployment on the server. No installation required. Just download,
unzip the files and place on the server. The utility does not require
any extra admin privileges to test or for the users to run the
utility. The IT folks in your organization do not need to be involved
in your decision to use the Auto FE Updater."

A dotNet solution is unacceptable to me. I've asked in a .Net C#
newsgroup. I don't recall the exact wording however you can't be
guaranteed that any particular framework is installed on any
particular client system. Therefore you must do an install which
requires admin privileges and IT department involvement thus the
spontaneity of the usage my utility would drastically decrease.

(Thus decreasing the likelihood of the developer using my utility
asking his employer to send me money. <smile>)

>[A pure unsubstantiated theory - MS is waiting for 64-bit Office.]

Office 2010 does come in a 64 bit version.

>2) Go back to a C/C++ platform.
>There is essentially nothing you can't do with 'C', given enough time. <g>

Yeah, well. <shudder>

>3) Go with Delphi.
>Slightly less guarantee of future support simply because Delphi is a
>competing vendor and simply because Borland itself is a tad shaky. (There
>were still questions last year if there would ever be a 64-bit version.)
>The platform is complete. It rivals any of the Microsoft platforms in terms
>of tools and options, and is superior to any of the alternative "BASICs". It
>has devoted users. You'll find much the same quality of support you get
>here.

At this point I'm simply monitoring threads here in this newsgroup.
Too many features to add right now to do any work on "what ifs".

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
From: Ralph on 21 Jan 2010 11:25
Mike B wrote:
>>
>> 3) Go with Delphi.
>> Slightly less guarantee of future support simply because Delphi is a
>> competing vendor and simply because Borland itself is a tad shaky.
>> (There
>
> No Borland. Embarcadero is the current owner.
> http://www.embarcadero.com/
>
> There is a substantial footprint of users worldwide.
>

Thanks for the update.

Other than SideKick (which was the bee's knees) I have never used any
Borland product full-time outside of evaluation or the occasional exposure
while consulting for a Borland shop.

I have always been confused the bewildering litany of changes in ownership,
spin-offs, and name-changes, plus the practically monthy announcements of
the ultimate doom of one or more of their products. It was enough to put me
off from ever purchasing them.

But their users hang in there, and in the case of Delphi the announcements
always seem premature and it continues to advance. They are as devoted and
as fanatical as any user can be, outside the Linix mob.

The poor unfortunates ... I wonder why the dotNeters don't go and
proselytize over there?

-ralph


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: VB6 Data missing when writing to a text file.
Next: Run Time Error 3265: Item cannot be found in the collection