Discussion:
Upgrading older VB programs (sans Project Files) to VB.NET
(too old to reply)
Ubiquitous
2012-01-04 23:23:10 UTC
Permalink
I have some old Visual Basic programs I'd like to upgrade to .NET because
they currently require obsolete drivers like "VBRUN300.DLL" to run. I
attempted to use the upgrade wizard but it appears it requires a project
VERSION 2.00
Begin Form Form1
BackColor = &H00C0C0C0&
BorderStyle = 1 'Fixed Single
Caption = "Dice roller"
ClientHeight = 1950
ClientLeft = 1230
ClientTop = 2625
ClientWidth = 2295
Height = 2355
Icon = SRDICE01.FRX:0000
Left = 1170
LinkTopic = "Form1"
MaxButton = 0 'False
ScaleHeight = 1950
ScaleWidth = 2295
Top = 2280
Width = 2415
Begin TextBox Text3
BackColor = &H00000000&
ForeColor = &H00FFFFFF&
Height = 285
Left = 1200
TabIndex = 7
Text = "0"
Top = 1560
Width = 975
End
Begin TextBox Text2
Height = 285
Left = 1560
TabIndex = 2
Text = "4"
Top = 480
Width = 615
End
Begin ListBox List1
Columns = 3
Height = 1005
Left = 120
Sorted = -1 'True
TabIndex = 4
Top = 840
Width = 975
End
Begin CommandButton Command1
BackColor = &H00C0C0C0&
Caption = "&Roll"
Default = -1 'True
Height = 375
Left = 1200
TabIndex = 3
Top = 840
Width = 975
End
Begin TextBox Text1
Height = 285
Left = 1560
TabIndex = 1
Text = "1"
Top = 120
Width = 615
End
Begin Label Label1
BackColor = &H00C0C0C0&
Caption = "Successes"
Height = 255
Index = 2
Left = 1200
TabIndex = 6
Top = 1320
Width = 975
End
Begin Label Label1
BackColor = &H00C0C0C0&
Caption = "&Target number"
Height = 255
Index = 1
Left = 120
TabIndex = 5
Top = 480
Width = 1335
End
Begin Label Label1
BackColor = &H00C0C0C0&
Caption = "&Number of dice"
Height = 255
Index = 0
Left = 120
TabIndex = 0
Top = 120
Width = 1335
End
End
Sub Command1_Click ()
list1.Clear
nsucc = 0
For i = 1 To Val(text1.Text)
v = 0
v = v + Int(Rnd(6) * 6 + 1)
If v Mod 6 = 0 Then GoTo reloop
If v >= Val(text2.Text) Then nsucc = nsucc + 1
list1.AddItem Format$(v, "00")
Next
text3.Text = Format$(nsucc)
End Sub
I have a feeling these pre-date VB 6 but wondered if there is a way to
systematically perform the upgrade without a project file instead of
making them from scratch.
Mayayana
2012-01-05 14:25:38 UTC
Permalink
You've posted to a ridiculous number of groups, some of which
are VB and some of which are VB.Net. VB and VB.Net are very
different things that share only a similar appearance. VB is for
Windows compiled software and is COM-centric. VB.Net is a Java
clone using a VM, designed to compete with Java in RAD server-
side software.

Your question should be posted only to .Net groups -- whis would
be the last 2 groups in your list. If you don't get an answer there,
you can try the online forums. Microsoft has discontinued
support for their own newsgroups and any MVP who wants to
keep a gold star on his/her forehead sticks to the online forums.
The forums are web-based. hard to use, moderated, and really
little more than a marketing device... but they're all that's left
in terms of Microsoft-supported discussion. You can find listings
here:

http://social.microsoft.com/Forums/en-US/categories
http://social.technet.microsoft.com/forums/en-US/categories/
http://social.msdn.microsoft.com/Forums/en/categories/
Thorsten Albers
2012-01-05 16:33:05 UTC
Permalink
Post by Ubiquitous
I have some old Visual Basic programs I'd like to upgrade to .NET because
they currently require obsolete drivers like "VBRUN300.DLL" to run. I
attempted to use the upgrade wizard but it appears it requires a project
Those files you are naming "make files" in fact are _the project files_. 16
bit VB (in your case VB 3.0) used the extension ".MAK" for project files.
It is rather unlikely that the upgrade wizard accepts project files from a
16 bit version of VB.
--
Thorsten Albers

gudea at gmx.de
mcnews
2012-01-05 17:06:24 UTC
Permalink
plus if you do get to a point where you can convert it will use a VB library/namespace so you wouldn't truly be converting. vb.net is not hard to learn and google is your friend.
Helmut_Meukel
2012-01-05 21:32:26 UTC
Permalink
Post by Ubiquitous
I have some old Visual Basic programs I'd like to upgrade to .NET because
they currently require obsolete drivers like "VBRUN300.DLL" to run. I
attempted to use the upgrade wizard but it appears it requires a project
VERSION 2.00
Begin Form Form1
[...]
Post by Ubiquitous
End
Sub Command1_Click ()
list1.Clear
nsucc = 0
For i = 1 To Val(text1.Text)
v = 0
v = v + Int(Rnd(6) * 6 + 1)
If v Mod 6 = 0 Then GoTo reloop
If v >= Val(text2.Text) Then nsucc = nsucc + 1
list1.AddItem Format$(v, "00")
Next
text3.Text = Format$(nsucc)
End Sub
I have a feeling these pre-date VB 6 but wondered if there is a way to
systematically perform the upgrade without a project file instead of
making them from scratch.
This is a 16-bit VB3 project. It's project file is the .MAK file.
You are lucky, because the .FRM and .BAS files were saved as text
(default was Binary).
But you still must first upgrade the projects to 32-bit (VB5 or VB6),
then you can try the upgrade wizard to .net.

Any as binaries saved VB3 projects can't be opened by VB5/6, you must
open those project again in VB3 and select the option "save as text"
before saving.

Having said all this, I think it's better to begin all these old programs
from scratch in VB.NET.
If it's a small program, it's still probably faster.
If it's a large project, the upgrade wizzard will produce code that
needs much work to get it running and the code will still be a mess.

Helmut.
Auric__
2012-01-06 02:50:53 UTC
Permalink
Post by Helmut_Meukel
Having said all this, I think it's better to begin all these old programs
from scratch in VB.NET.
If it's a small program, it's still probably faster.
If it's a large project, the upgrade wizzard will produce code that
needs much work to get it running and the code will still be a mess.
Very much agreed. Restarting from scratch is likely to give you an overall
better program than importing, IMO.
--
The more you say, the less I understand.
Tony Toews
2012-01-10 03:29:34 UTC
Permalink
Post by Ubiquitous
I have some old Visual Basic programs I'd like to upgrade to .NET because
they currently require obsolete drivers like "VBRUN300.DLL" to run.
Or upgrade them to VB6 as the VB6 runtime is part of the OS from
Windows 2000 to Windows 8. If you can locate the VB6 IDE/compiler
for a decent price on Ebay then that may be all that is required.
Unless third party controls are involved but there likely are
replacements available.

I do see several on eBay for about $140 and up. Sort by price to get
the books out of the way.

Note that the eBay item "Microsoft MSDN Library Visual Studio 6 6.0
Basic Help" is just the help for VB6/VS6 and does not contain the
actual IDE/compiler.

(Sheesh, why would you be selling a VB6 certification exam guide on
eBay?)

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/
Mayayana
2012-01-10 14:22:14 UTC
Permalink
| Or upgrade them to VB6 as the VB6 runtime is part of the OS from
| Windows 2000 to Windows 8.

Indeed. One wonders about the relevance of .Net going forward.
Especially on the Desktop. (Presumably it will still be relevant
on corporate servers.) As I understand it, Windows 8 will have
Metro apps, which will be little more than scripted webpages, must
be approved by MS, and MS gets a cut of any sales income.

Win8 is still expected to have normal compiled software, which
will not suffer the restrictions and control of Metro apps, but will
be cast as fuddy duddy technology.

VB is still relevant for compiled software. Javascript is increasingly
relevant for $2 trinket software and games. .Net is not optimized
for either. It's hard to find a clear, complete story on Win8 and
Metro, but it sounds like .Net will be "repurposed" as a javascript
IDE.
Tom Shelton
2012-01-10 17:14:33 UTC
Permalink
Post by Mayayana
Post by Tony Toews
Or upgrade them to VB6 as the VB6 runtime is part of the OS from
Windows 2000 to Windows 8.
Indeed. One wonders about the relevance of .Net going forward.
Especially on the Desktop. (Presumably it will still be relevant
on corporate servers.) As I understand it, Windows 8 will have
Metro apps, which will be little more than scripted webpages, must
be approved by MS, and MS gets a cut of any sales income.
Win8 is still expected to have normal compiled software, which
will not suffer the restrictions and control of Metro apps, but will
be cast as fuddy duddy technology.
VB is still relevant for compiled software. Javascript is
increasingly relevant for $2 trinket software and games. .Net is not
optimized for either. It's hard to find a clear, complete story on
Win8 and Metro, but it sounds like .Net will be "repurposed" as a
javascript IDE.
You seriously don't know what your talking about... .NET is a BIG part
of windows 8 and metro. HTML/JavaScript is just one way to create
limited functionality metro apps. Most apps will be C#/VB or C++ using
wpf as the front end. Some parts of the .net runtime will be mapped to
winrt - but, .net is not dead.
--
Tom Shelton
Mayayana
2012-01-10 22:04:48 UTC
Permalink
| You seriously don't know what your talking about... .NET is a BIG part
| of windows 8 and metro.

We'll see. From what I read WinRT is as much of
a wrapper-pretending-to-be-an-API as .Net is. May
as well script it.

Geez, it's taking a lot to rouse you
out of the woodwork these days, Tom. :)

| HTML/JavaScript is just one way to create
| limited functionality metro apps. Most apps will be C#/VB or C++ using
| wpf as the front end. Some parts of the .net runtime will be mapped to
| winrt - but, .net is not dead.
|
| --
| Tom Shelton
|
|
Schmidt
2012-01-11 20:02:17 UTC
Permalink
... but, .net is not dead.
It's now in the same way "not dead", as VB6 is...
Welcome to the club!

Really funny, that we are back now, to the combination
of 'C++ and COM' as the only recommended way to develop
serious and new "native Desktop-Apps" (because any other
(MS-)tools cannot be considered "future-proof" or
"safe with regards to line-of-code-investments").

IIRC we had this C++/COM combination already some 15 years ago,
followed up by VB5/6-RAD to "develop COM-Apps even faster".
So VB6 is yet a good tool, working "directly on top" of
the current "state of the art tech".

That much to selling us .NET as "technologic innovation"
and urging us "to move on".
Seems that the serious code-bases will always be C/C++ (as the
best compromise, to abstract a language from the hardware).

All the rest on top of it is (at least in MS' Book)
apparently considered "throw-away software".

The invention of COM, as a kind of objectoriented,
(class-hosting and selfdescribing) library-format
seems at least a well-surviving idea. As was VB-classic,
as a glue-language for COMponents as well. It does
its job even today, and will do so also on Win8.

Aside from, that the new RAD-kid on the "blog" is now
apparently the HTML/JS combination (and accompanying new
IDEs, to "glue stuff together this way", including
automatic uploads into the great new world of App-Stores).

Let's see, how this works out - and what VB6/COM-based
Apps on the Win8-Desktop are good for in the long run.

Olaf
Henning
2012-01-12 14:33:39 UTC
Permalink
Post by Schmidt
... but, .net is not dead.
It's now in the same way "not dead", as VB6 is...
Welcome to the club!
Really funny, that we are back now, to the combination
of 'C++ and COM' as the only recommended way to develop
serious and new "native Desktop-Apps" (because any other
(MS-)tools cannot be considered "future-proof" or
"safe with regards to line-of-code-investments").
IIRC we had this C++/COM combination already some 15 years ago,
followed up by VB5/6-RAD to "develop COM-Apps even faster".
So VB6 is yet a good tool, working "directly on top" of
the current "state of the art tech".
That much to selling us .NET as "technologic innovation"
and urging us "to move on".
Seems that the serious code-bases will always be C/C++ (as the
best compromise, to abstract a language from the hardware).
All the rest on top of it is (at least in MS' Book)
apparently considered "throw-away software".
The invention of COM, as a kind of objectoriented,
(class-hosting and selfdescribing) library-format
seems at least a well-surviving idea. As was VB-classic,
as a glue-language for COMponents as well. It does
its job even today, and will do so also on Win8.
Aside from, that the new RAD-kid on the "blog" is now
apparently the HTML/JS combination (and accompanying new
IDEs, to "glue stuff together this way", including
automatic uploads into the great new world of App-Stores).
Let's see, how this works out - and what VB6/COM-based
Apps on the Win8-Desktop are good for in the long run.
Olaf
Also code safety:
Your .NET decompiler alternative has arrived! Telerik JustDecompile is a
powerful yet free-of-charge tool, which enables you to effortlessly explore
and analyze compiled .NET assemblies at the click of a button.

/Henning
GS
2012-01-13 04:58:17 UTC
Permalink
Post by Henning
Post by Schmidt
... but, .net is not dead.
It's now in the same way "not dead", as VB6 is...
Welcome to the club!
Really funny, that we are back now, to the combination
of 'C++ and COM' as the only recommended way to develop
serious and new "native Desktop-Apps" (because any other
(MS-)tools cannot be considered "future-proof" or
"safe with regards to line-of-code-investments").
IIRC we had this C++/COM combination already some 15 years ago,
followed up by VB5/6-RAD to "develop COM-Apps even faster".
So VB6 is yet a good tool, working "directly on top" of
the current "state of the art tech".
That much to selling us .NET as "technologic innovation"
and urging us "to move on".
Seems that the serious code-bases will always be C/C++ (as the
best compromise, to abstract a language from the hardware).
All the rest on top of it is (at least in MS' Book)
apparently considered "throw-away software".
The invention of COM, as a kind of objectoriented,
(class-hosting and selfdescribing) library-format
seems at least a well-surviving idea. As was VB-classic,
as a glue-language for COMponents as well. It does
its job even today, and will do so also on Win8.
Aside from, that the new RAD-kid on the "blog" is now
apparently the HTML/JS combination (and accompanying new
IDEs, to "glue stuff together this way", including
automatic uploads into the great new world of App-Stores).
Let's see, how this works out - and what VB6/COM-based
Apps on the Win8-Desktop are good for in the long run.
Olaf
Your .NET decompiler alternative has arrived! Telerik JustDecompile is a
powerful yet free-of-charge tool, which enables you to effortlessly explore
and analyze compiled .NET assemblies at the click of a button.
/Henning
This is why LogicNP has available Crypto Obfuscator to thwart
decompiling .Net apps.
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Tom Shelton
2012-01-12 16:34:11 UTC
Permalink
Post by Schmidt
... but, .net is not dead.
It's now in the same way "not dead", as VB6 is...
Welcome to the club!
VB6 has been deprecated - .NET has not. It is still being actively
developed. New capabilities, new technologies being added, and new
versions being produced. So, I fail to see how .NET is anything like
VB6. Sure, there will be some changes comming. It's 10 year old tech
- of course it's going to change, and I expect at some point it will be
deprecated...
Post by Schmidt
Really funny, that we are back now, to the combination
of 'C++ and COM' as the only recommended way to develop
serious and new "native Desktop-Apps" (because any other
(MS-)tools cannot be considered "future-proof" or
"safe with regards to line-of-code-investments").
What I want to know is where you got that C++ and COM is the only
recommended way to develop metro apps. Have you even loaded VS11? I
guarentee you that VB and C# are there.
Post by Schmidt
IIRC we had this C++/COM combination already some 15 years ago,
followed up by VB5/6-RAD to "develop COM-Apps even faster".
So VB6 is yet a good tool, working "directly on top" of
the current "state of the art tech".
I think it's more like C++/WinRT - COM is part of winrt, but asfict
it's not out in the forefront. Just like COM is part of .NET - but,
it's pretty much invisible for the most part.
Post by Schmidt
That much to selling us .NET as "technologic innovation"
and urging us "to move on".
Seems that the serious code-bases will always be C/C++ (as the
best compromise, to abstract a language from the hardware).
All the rest on top of it is (at least in MS' Book)
apparently considered "throw-away software".
The invention of COM, as a kind of objectoriented,
(class-hosting and selfdescribing) library-format
seems at least a well-surviving idea. As was VB-classic,
as a glue-language for COMponents as well. It does
its job even today, and will do so also on Win8.
Aside from, that the new RAD-kid on the "blog" is now
apparently the HTML/JS combination (and accompanying new
IDEs, to "glue stuff together this way", including
automatic uploads into the great new world of App-Stores).
Let's see, how this works out - and what VB6/COM-based
Apps on the Win8-Desktop are good for in the long run.
Olaf
You are living in some sort of dream world, where all tech is good
forever. Doesn't happen. And, I seriously don't see how my .net code
base is in anyway threatend going forward at this time. Might have to
do some new UI's - but, since all of my real code is in libraries, I
really don't see this as a huge deal.
--
Tom Shelton
Schmidt
2012-01-13 19:17:10 UTC
Permalink
Post by Tom Shelton
Post by Schmidt
... but, .net is not dead.
It's now in the same way "not dead", as VB6 is...
Welcome to the club!
VB6 has been deprecated - .NET has not.
The VB6-IDE is not *supported* anymore - the essential
technology under the covers (an underlying C/C++ compiler
and COM is by no means deprecated).

On the other hand, Winforms are deprecated in
the meantime, as is the usage of Silverlight...
(more to come, just wait).
Post by Tom Shelton
Post by Schmidt
Really funny, that we are back now, to the combination
of 'C++ and COM' as the only recommended way to develop
serious and new "native Desktop-Apps" (because any other
(MS-)tools cannot be considered "future-proof" or
"safe with regards to line-of-code-investments").
What I want to know is where you got that C++ and COM is
the only recommended way to develop metro apps.
I was not talking about "Metro-Apps" - I was talking
about "native Desktop-Apps" - and the only secure
way (the word "recommended" was not that well-choosen)
in terms of code-investments is apparently C/C++
(33 year old "technology" in the meantime).
Post by Tom Shelton
You are living in some sort of dream world, where all
tech is good forever. Doesn't happen.
That's what you try to sell us for years now.
I say, tech *can* be "good forever", when there's not
much left to optimize (just look at "the wheel" <g>).

And apparently C/C++ is such a wheel.
Everything on top of it (in case you want to
construct a bicycle for example) - is just
different shortcuts (e.g. if you use different
frames (aka frameworks/libraries) in combination
with a highlevel-language, to be able to
build "customized cycles" a little bit faster).

And the VBClassic-runtime-lib (in conjunction with
the VBClassic language) does its job just fine
at the moment - as well as in the near future.

And it is "less far" from the current base-tech
(C/C++ and COM) than .NET is - that's my whole point.

It remains to be seen (I'd say, let's talk about it again
in 10 years or so), whether a thin runtime-layer on top
of C/C++ - or a bloated VM, will better survive over time.

From my point of view, it is you who's living in a
dream world, not acknowledging, that both approaches
(from MS' point of view) were only temporary cash-cows,
sold to "crowds of RAD-believers".

The difference between .NET- and "still VB6"-users is,
that the latter ones recognized "the pattern" much
earlier (fool me once) - and didn't invest that much
time again into "the next distraction".

Olaf
GS
2012-01-13 19:31:28 UTC
Permalink
Post by Schmidt
Post by Tom Shelton
Post by Schmidt
... but, .net is not dead.
It's now in the same way "not dead", as VB6 is...
Welcome to the club!
VB6 has been deprecated - .NET has not.
The VB6-IDE is not *supported* anymore - the essential
technology under the covers (an underlying C/C++ compiler
and COM is by no means deprecated).
On the other hand, Winforms are deprecated in
the meantime, as is the usage of Silverlight...
(more to come, just wait).
Post by Tom Shelton
Post by Schmidt
Really funny, that we are back now, to the combination
of 'C++ and COM' as the only recommended way to develop
serious and new "native Desktop-Apps" (because any other
(MS-)tools cannot be considered "future-proof" or
"safe with regards to line-of-code-investments").
What I want to know is where you got that C++ and COM is
the only recommended way to develop metro apps.
I was not talking about "Metro-Apps" - I was talking
about "native Desktop-Apps" - and the only secure
way (the word "recommended" was not that well-choosen)
in terms of code-investments is apparently C/C++
(33 year old "technology" in the meantime).
Post by Tom Shelton
You are living in some sort of dream world, where all
tech is good forever. Doesn't happen.
That's what you try to sell us for years now.
I say, tech *can* be "good forever", when there's not
much left to optimize (just look at "the wheel" <g>).
And apparently C/C++ is such a wheel.
Everything on top of it (in case you want to
construct a bicycle for example) - is just
different shortcuts (e.g. if you use different
frames (aka frameworks/libraries) in combination
with a highlevel-language, to be able to
build "customized cycles" a little bit faster).
And the VBClassic-runtime-lib (in conjunction with
the VBClassic language) does its job just fine
at the moment - as well as in the near future.
And it is "less far" from the current base-tech
(C/C++ and COM) than .NET is - that's my whole point.
It remains to be seen (I'd say, let's talk about it again
in 10 years or so), whether a thin runtime-layer on top
of C/C++ - or a bloated VM, will better survive over time.
From my point of view, it is you who's living in a
dream world, not acknowledging, that both approaches
(from MS' point of view) were only temporary cash-cows,
sold to "crowds of RAD-believers".
The difference between .NET- and "still VB6"-users is,
that the latter ones recognized "the pattern" much
earlier (fool me once) - and didn't invest that much
time again into "the next distraction".
Olaf
Very well said!
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Tom Shelton
2012-01-13 20:22:55 UTC
Permalink
Post by Schmidt
Post by Tom Shelton
Post by Schmidt
... but, .net is not dead.
It's now in the same way "not dead", as VB6 is...
Welcome to the club!
VB6 has been deprecated - .NET has not.
The VB6-IDE is not *supported* anymore - the essential
technology under the covers (an underlying C/C++ compiler
and COM is by no means deprecated).
On the other hand, Winforms are deprecated in
the meantime, as is the usage of Silverlight...
(more to come, just wait).
I don't know if youv'e been paying attention... Win32 is pretty much
deprecated.
Post by Schmidt
Post by Tom Shelton
Post by Schmidt
Really funny, that we are back now, to the combination
of 'C++ and COM' as the only recommended way to develop
serious and new "native Desktop-Apps" (because any other
(MS-)tools cannot be considered "future-proof" or
"safe with regards to line-of-code-investments").
What I want to know is where you got that C++ and COM is
the only recommended way to develop metro apps.
I was not talking about "Metro-Apps" - I was talking
about "native Desktop-Apps" - and the only secure
way (the word "recommended" was not that well-choosen)
in terms of code-investments is apparently C/C++
(33 year old "technology" in the meantime).
Well, in windows 8 and beyond - Metro is the native desktop. WinRT is
the api. Win32 and the old dekstop are legacy.

I still fail to see your point... Winforms/silverlight and all .net
apps will continue to run and function just as they always have on the
legacy desktop. What is it that you are trying to get at here?
Post by Schmidt
Post by Tom Shelton
You are living in some sort of dream world, where all
tech is good forever. Doesn't happen.
That's what you try to sell us for years now.
I say, tech *can* be "good forever", when there's not
much left to optimize (just look at "the wheel" <g>).
Sorry - but, if that was the case we would all still be using COBOL and
Fortran.
Post by Schmidt
And apparently C/C++ is such a wheel.
C/C++ are fairly close to the metal - and I love them both. But, even
they have evolved over the years. Have you been looking at the new
standards? Lots of features we have in C# being added - lambdas, etc.
Post by Schmidt
Everything on top of it (in case you want to
construct a bicycle for example) - is just
different shortcuts (e.g. if you use different
frames (aka frameworks/libraries) in combination
with a highlevel-language, to be able to
build "customized cycles" a little bit faster).
C++ are just layers on top of assembly. So what?
Post by Schmidt
And the VBClassic-runtime-lib (in conjunction with
the VBClassic language) does its job just fine
at the moment - as well as in the near future.
Not in the new desktop. And, not on ARM. VB6 will continue to work on
the legacy desktop, which we know will be phased out in the not to many
versions hence.

In other words - the end is nigh.
Post by Schmidt
And it is "less far" from the current base-tech
(C/C++ and COM) than .NET is - that's my whole point.
C/C++ will not be using COM directly in the new paradigm. They, along
with C#/VB/JavaScript will be using WinRT. WinRT does use COM - in
fact, it's very important for the internals of WinRT, but the average
C++ dev developing for the new desktop is not going to care about that.
Post by Schmidt
It remains to be seen (I'd say, let's talk about it again
in 10 years or so), whether a thin runtime-layer on top
of C/C++ - or a bloated VM, will better survive over time.
You guys and your bloated VM thing are really getting tiresome.

First off - the runtime is not a thin layer over c/c++. It is a layer
over the win32 api - but, that is native code, ie machine code. It is
irrelavent that a lot of it was done in C (and I mean straigth C).

The framework, is a set of libraries - that is all. It doesn't all get
loaded at runtime. They don't all get used by any single application.
The size on disk and the download time of said framework is pretty much
irrelavent give modern broadband and disk sizes. Both, of which are
mostly irrelavent - since, like the VB6 runtimes - it is part of the
base OS install now.

You act as if I have some problem with C/C++? I do not. In fact, I
love C++. It was my first programming language - I still do stuff in
it on occasion. It's the love for C++ and C style syntax, that made me
move to C# when I had to move to .NET.
Post by Schmidt
From my point of view, it is you who's living in a
dream world, not acknowledging, that both approaches
(from MS' point of view) were only temporary cash-cows,
sold to "crowds of RAD-believers".
The difference between .NET- and "still VB6"-users is,
that the latter ones recognized "the pattern" much
earlier (fool me once) - and didn't invest that much
time again into "the next distraction".
That is simply the most ridiculous bunch of rubbish I have ever read.
VB6 is simply irrelavent - and about to fade completely into the foot
notes of history. If you can't see that, than you simply aren't paying
attention. Smart tv's, smart camera's, tablets, phones, etc - they are
becomming the center of the computing industry. Which, basically means
even MS is struggling to stay relavent right now, against the on
slaught of Android/iOS. And that means, java or C (well, objective-c
for ios :) ). At least, with C# there are tools for targeting android
and even ios. Haven't seen any for VB6... And, worse case - it's not
that difficult to port my C# libraries to Java (the major programming
environment in the android echo system).

The fact, is the world has moved on and left you behind.
--
Tom Shelton
Mayayana
2012-01-13 21:07:25 UTC
Permalink
|
| I don't know if youv'e been paying attention... Win32 is pretty much
| deprecated.
|

It's the basis of WinRT.
http://tirania.org/blog/archive/2011/Sep-15.html

http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx
"most if not all WinRT APIs are wrappers on top of existing functionality in
Win32 or COM components."

If you search on WinRT and API you find lots of
people saying that WinRT is "finally replacing the
old, decrepit API". And you'll find a few people, like
the links above, pointing out that WinRT, like .Net
before it, is no more than a [bloated] sandboxing
wrapper on top of the basic OS.

| Well, in windows 8 and beyond - Metro is the native desktop. WinRT is
| the api. Win32 and the old dekstop are legacy.
| ..... VB6 will continue to work on
| the legacy desktop, which we know will be phased out in the not to many
| versions hence.
|

Legacy... legacy... PCs are legacy. Mouse and keyboard
are legacy. The Win API is legacy. VB is legacy. Desktops
and file systems are legacy. Whatever "legacy" is, it sounds
rather useful and comnprehensive.
Tom Shelton
2012-01-13 21:14:01 UTC
Permalink
Post by Mayayana
Post by Tom Shelton
I don't know if youv'e been paying attention... Win32 is pretty
much deprecated.
It's the basis of WinRT.
http://tirania.org/blog/archive/2011/Sep-15.html
http://blogs.microsoft.co.il/blogs/sasha/archive/2011/09/15/winrt-and-net-in-windows-8.aspx
"most if not all WinRT APIs are wrappers on top of existing
functionality in Win32 or COM components."
If you search on WinRT and API you find lots of
people saying that WinRT is "finally replacing the
old, decrepit API". And you'll find a few people, like
the links above, pointing out that WinRT, like .Net
before it, is no more than a [bloated] sandboxing
wrapper on top of the basic OS.
You can not access Win32 functions directly in a metro app. For all
practicle purposes, it is dead to the a developer targeting the metro
interface. Period. To think that WinRT does not make use of Win32 at
this point would be naive at best.
Post by Mayayana
Post by Tom Shelton
Well, in windows 8 and beyond - Metro is the native desktop. WinRT
is the api. Win32 and the old dekstop are legacy.
..... VB6 will continue to work on
the legacy desktop, which we know will be phased out in the not to
many versions hence.
Legacy... legacy... PCs are legacy. Mouse and keyboard
are legacy. The Win API is legacy. VB is legacy. Desktops
and file systems are legacy. Whatever "legacy" is, it sounds
rather useful and comnprehensive.
Keep saying that when you want your apps to run on Windows 8 arm
devices...
--
Tom Shelton
Mayayana
2012-01-14 01:58:12 UTC
Permalink
| You can not access Win32 functions directly in a metro app. For all
| practicle purposes, it is dead to the a developer targeting the metro
| interface. Period. To think that WinRT does not make use of Win32 at
| this point would be naive at best.
|

Exactly. It's another wrapper in API's clothing.
I don't want to write Metro trinkets. I doubt
that you really want to either. And it's *very*
unlikely that anyone's going to make money
doing that.

It'll be interesting to see how it pans out. Metro
is completely unrealistic for PCs. Nokia/Win phones
are getting great reviews, but no one is buying them.
Tablets never made much sense in the first place,
so it's hard to know how that will work out. No
matter how you look at it, people are not going to
be writing docs and spreadsheets on a swipe screen.

Microsoft tried to move developers out of the system
with .Net. They're doing it further with Metro. The plan
sounds a lot like trying to cash in on the Apple model:
Tight control. Developers have to be approved. MS gets
a 30% cut of software sales. That might happen, but it's
not going to happen on a PC. And that's the only kind
of software I'm interested in writing or using.

I'm actually very curious. On the surface, at least,
Microsoft seems to be turning away from corporate and
toward the entertainment market. So corporate PCs with
Win8 will be set to Desktop while non-business PCs will
be tuned to Metro, where people will spend their time
updating their Facebook page on their swipe screen?
That vision is so untenable in so many ways that I'm
quite curious to see how it all shakes out.

It seems clear that VB will be usable for Desktop
software as long as people can actually control their
own Windows PCs. And .Net will continue to be relevant
on corporate intranets, if nowhere else. If Metro survives
at all it will be in an entirely different arena.
Tony Toews
2012-01-20 02:10:22 UTC
Permalink
On Fri, 13 Jan 2012 20:58:12 -0500, "Mayayana"
Post by Mayayana
Tablets never made much sense in the first place,
I very much like my Kobo Vox 7" tablet. But then all I really do on
it is read eBooks and browse the web. I don't do much else with it.
I certainly don't type more than a sentence on it while in Facebook.
Post by Mayayana
so it's hard to know how that will work out. No
matter how you look at it, people are not going to
be writing docs and spreadsheets on a swipe screen.
Agreed. Although maybe with an external keyboard I can see some folks
using it to do some light work.

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/
Schmidt
2012-01-13 23:12:26 UTC
Permalink
Post by Tom Shelton
Post by Schmidt
On the other hand, Winforms are deprecated in
the meantime, as is the usage of Silverlight...
(more to come, just wait).
I don't know if youv'e been paying attention...
Win32 is pretty much deprecated.
That's misinformation, because MS cannot afford,
to throw out the Win32-API-layer any time soon.
The relation of Win32-Apps/Win64-Apps is currently
about 80/20 I'd say - a long way for MS, to be
able to pull the plug there.
Post by Tom Shelton
Well, in windows 8 and beyond - Metro is the
native desktop.
Not in my book - Metro/WinRT is foremost
only "an attempt to support a trend" (touch-
screens and non-x86 CPUs).

BTW, I've recently sold Desktop-Systems, which offered
(at request) both, a TouchScreen-interface and
alternatively "classic input" over Mouse/Keyboard.
What happened after a few weeks of playing around
is, that on my last visit everybody was back
using the Mouse exclusively.

So (IMO) there's just no need, to offer Touch-Interfaces
for "normal Desktop-Work" with classic Notebooks
or PC/TFT combinations.

Touchscreens make sense on devices without a Mouse
(Tablets and Phones - or large presentation-screens) -
nowhere else.

And there's rumors, that the real Desktop (running
on the classic Win32/64-API) will be made the default
(at least in Win8-company-versions, analogous to Win7).
Post by Tom Shelton
I still fail to see your point...
Winforms/silverlight and all .net apps will continue
to run and function just as they always have on the legacy
desktop. What is it that you are trying to get at here?
I'm repeating myself... they are in the same way
"dead, deprecated, whatever" as VB6 is - so let me
retype your above sentence:

"VB6 and VB6-apps will continue to run and function
just as they always have on the legacy desktop.
What is it that you are trying to get at here?"
<g>
Post by Tom Shelton
Post by Schmidt
And the VBClassic-runtime-lib (in conjunction with
the VBClassic language) does its job just fine
at the moment - as well as in the near future.
Not in the new desktop.
What exactly *is* the "new desktop"?
These Touch-Interface-optimized Entry-Screen-Tiles,
nobody who does serious Desktop-work will use
in the end?

Aside from that, it should not be that hard,
to bring a native VB6-App into this Tile-Upstarter.
And since WinRT is COM, it should also not be that
hard, to address it from VB6 - I'm sure this topic
will be "investigated" here in the community,
as soon as Win8 is out.
Post by Tom Shelton
And, not on ARM.
WTFuzz - here you come again, armed with the ARM-argument.
If one wants to address 95% of all Tablet- and Phone-
Users, he writes his App with either the Android- or
the Apple-Tools (Java or Objective-C).

And just in case I want to address the poor souls,
who indeed bought a Win8/ARM-device, then
Speaking for myself, I would write small HTML/JS-Apps
for devices like that. This way I could even address
the poor souls, who accidentally bought Win8/ARM-gadgets.

In either case, the applications which run on these
devices are not the classical, complex branch-solutions
which were/are the main-field of VB6-Devs. These new
mobile Apps are usually small, handling only a small
volume of data, not that many "screens to code" -
so the implementation-language does not matter that much.
The larger, complex Apps which are used on these
devices (Google-Maps or stuff like that), usually run
online anyways (in the Mobile-Browsers), so what you
need for development in these complex cases is an environment,
which can create WebApps - and for that there's loads
of alternatives to MS-stuff.
Post by Tom Shelton
VB6 will continue to work on the legacy desktop,
which we know will be phased out in the not to many
versions hence.
"Which we know will be phased out..." - where can
I want to read more about that - do you have a
link or something?

Your so called "legacy Desktop" is still, also in
Win8, the main-workhorse for all kind of productive
labour - as I wrote further above already - the users
just "don't touch" the new stuff, as soon as a Mouse
is in reach.

Maybe we see a kind of "Vista-Effekt" for the new
Tile-Desktop (at least in productive environments).
Post by Tom Shelton
In other words - the end is nigh.
That is true of course, always was - for all of us...;-)
Post by Tom Shelton
Post by Schmidt
And it is "less far" from the current base-tech
(C/C++ and COM) than .NET is - that's my whole point.
...
First off - the runtime is not a thin layer over c/c++.
I didn't wrote that.
Oh - you mean the WinRT (not the VBClassic-Runtime-lib)?
In this case I have to tell you, that the C/C++ guys
are very happy with WinRT, because they can bypass
any "intermediate .NET-layer" (you know, the "bloated
VM" I wrote about earlier <g>), to get access to the
system much more directly.
And of course the WinRT sits atop of C/C++ libs
(currently the classic Win-API on x86-machines) -
but on top of the WinAPI and WinRT comes the consuming
Application-Code, which (if you don't want bloat) should be
written also in C/C++. So, the "thin layer thingy"
works both ways of course...

Here the happy statement of a C++-developer -
at the end of the article (in the chapter 'Conclusion') on:
http://www.codeproject.com/KB/cpp/WinRTVisualCppIntro.aspx

"...But for faster applications with smaller memory footprints
where performance is the key focal point, using C++ to write
Metro apps is the way to go because when you do that it's
metal on metal! The renaissance is here, finally."
Post by Tom Shelton
You act as if I have some problem with C/C++?
How do you come to this conclusion? I'm pretty
sure, I've done more work (manifested in megabytes
of VBclassic-adapted binaries) in C/C++ than you.
Post by Tom Shelton
I do not. In fact, I love C++.
Then go on, use it - there's even better suited
Newsgroups to talk about your love or C++ and all that.
Post by Tom Shelton
Post by Schmidt
From my point of view, it is you who's living in a
dream world, not acknowledging, that both approaches
(from MS' point of view) were only temporary cash-cows,
sold to "crowds of RAD-believers".
The difference between .NET- and "still VB6"-users is,
that the latter ones recognized "the pattern" much
earlier (fool me once) - and didn't invest that much
time again into "the next distraction".
That is simply the most ridiculous bunch of rubbish
I have ever read. VB6 is simply irrelavent -
If you say so - but again, in the same way as .NET is
becoming more and more irrelevant.
Post by Tom Shelton
and about to fade completely into the foot
notes of history.
In the same way as .NET does.
Post by Tom Shelton
If you can't see that, than you simply aren't paying
attention. Smart tv's, smart camera's, tablets, phones, etc
Yeah, sure.
Smart anything - as well as "i like" or "fast and fluent"
or other marketing-rubbish you apparently are fond of...
Post by Tom Shelton
they are becomming the center of the computing industry.
Prebuilt devices with prebuilt vendor-apps, accompanied
by already saturated "App-markets". That's what the
"new developer-generation" has to struggle with
(to get their feets in).

What remains (for existing small software-companies
and selfemployed devs with a bit of a business-background)
is more or less (still) the branch-applications,
which wants to be run on a normal Desktop, on a
normal PC (with mouse and keyboard).
Post by Tom Shelton
Which, basically means even MS is struggling to stay relavent
right now, against the on slaught of Android/iOS.
And that means, java or C (well, objective-c for ios :)
Glad you admit that.
It's an important point - and BTW the base of my assumption,
that my statement ".NET is becoming more and more irrelevant too"
is becoming a true one.
Post by Tom Shelton
At least, with C# there are tools for targeting android and even ios.
Yes, as I wrote above, the few percent which are left
for MS in this tv/table/phone consumer-market can be addressed
either with C#/VB.NET/C++ or with just simple HTML/JS.
And as said, should I ever be inconvenienced with the
requirement, to write a (probably then accompanying a larger DeskApp)
small application for a tablet or phone-device, then I'd
do it in HTML/JS - since all these platforms come with a
mobile-browser. There's even jQuery-abstraction-classes
for the touch-interface-events for most of them.
Post by Tom Shelton
Haven't seen any for VB6...
As said, not needed - for Desktop-stuff VBClassic is more
than enough - for "fun- and simple consumer-stuff" HTML/JS
should be sufficient too.
Post by Tom Shelton
And, worse case - it's not that difficult to port my C#
libraries to Java (the major programming environment in the
android echo system).
What are these libraries, if I may ask that?
What sense do they make, ported to a small-screen-device?
Aside from that, wouldn't it be better, to leave them
"as is" and just put their functionality at the serverside
and just show the computed (HTML/JSON) results on these small
screens (in a few WebPages), hmm?

You see, why I ask that - do you? Because exactly
the same way is open for any COM-library, written
in VBClassic (to put them into place behind a WebServer).
Post by Tom Shelton
The fact, is the world has moved on and left you behind.
Coming from you I can live with that, I think... ;-)


Olaf
Henning
2012-01-13 23:24:31 UTC
Permalink
Post by Schmidt
Post by Tom Shelton
Post by Schmidt
On the other hand, Winforms are deprecated in
the meantime, as is the usage of Silverlight...
(more to come, just wait).
I don't know if youv'e been paying attention...
Win32 is pretty much deprecated.
That's misinformation, because MS cannot afford,
to throw out the Win32-API-layer any time soon.
The relation of Win32-Apps/Win64-Apps is currently
about 80/20 I'd say - a long way for MS, to be
able to pull the plug there.
Post by Tom Shelton
Well, in windows 8 and beyond - Metro is the
native desktop.
Not in my book - Metro/WinRT is foremost
only "an attempt to support a trend" (touch-
screens and non-x86 CPUs).
BTW, I've recently sold Desktop-Systems, which offered
(at request) both, a TouchScreen-interface and
alternatively "classic input" over Mouse/Keyboard.
What happened after a few weeks of playing around
is, that on my last visit everybody was back
using the Mouse exclusively.
I have the same experience, they used it for a month, then went back to
kb/mouse. Their expensive touchscreens are only "normal" monitors today.
Post by Schmidt
So (IMO) there's just no need, to offer Touch-Interfaces
for "normal Desktop-Work" with classic Notebooks
or PC/TFT combinations.
Touchscreens make sense on devices without a Mouse
(Tablets and Phones - or large presentation-screens) -
nowhere else.
And there's rumors, that the real Desktop (running
on the classic Win32/64-API) will be made the default
(at least in Win8-company-versions, analogous to Win7).
Post by Tom Shelton
I still fail to see your point...
Winforms/silverlight and all .net apps will continue
to run and function just as they always have on the legacy
desktop. What is it that you are trying to get at here?
I'm repeating myself... they are in the same way
"dead, deprecated, whatever" as VB6 is - so let me
"VB6 and VB6-apps will continue to run and function
just as they always have on the legacy desktop.
What is it that you are trying to get at here?"
<g>
Post by Tom Shelton
Post by Schmidt
And the VBClassic-runtime-lib (in conjunction with
the VBClassic language) does its job just fine
at the moment - as well as in the near future.
Not in the new desktop.
What exactly *is* the "new desktop"?
These Touch-Interface-optimized Entry-Screen-Tiles,
nobody who does serious Desktop-work will use
in the end?
Aside from that, it should not be that hard,
to bring a native VB6-App into this Tile-Upstarter.
And since WinRT is COM, it should also not be that
hard, to address it from VB6 - I'm sure this topic
will be "investigated" here in the community,
as soon as Win8 is out.
Post by Tom Shelton
And, not on ARM.
WTFuzz - here you come again, armed with the ARM-argument.
If one wants to address 95% of all Tablet- and Phone-
Users, he writes his App with either the Android- or
the Apple-Tools (Java or Objective-C).
And just in case I want to address the poor souls,
who indeed bought a Win8/ARM-device, then
Speaking for myself, I would write small HTML/JS-Apps
for devices like that. This way I could even address
the poor souls, who accidentally bought Win8/ARM-gadgets.
In either case, the applications which run on these
devices are not the classical, complex branch-solutions
which were/are the main-field of VB6-Devs. These new
mobile Apps are usually small, handling only a small
volume of data, not that many "screens to code" -
so the implementation-language does not matter that much.
The larger, complex Apps which are used on these
devices (Google-Maps or stuff like that), usually run
online anyways (in the Mobile-Browsers), so what you
need for development in these complex cases is an environment,
which can create WebApps - and for that there's loads
of alternatives to MS-stuff.
Post by Tom Shelton
VB6 will continue to work on the legacy desktop,
which we know will be phased out in the not to many
versions hence.
"Which we know will be phased out..." - where can
I want to read more about that - do you have a
link or something?
Your so called "legacy Desktop" is still, also in
Win8, the main-workhorse for all kind of productive
labour - as I wrote further above already - the users
just "don't touch" the new stuff, as soon as a Mouse
is in reach.
Maybe we see a kind of "Vista-Effekt" for the new
Tile-Desktop (at least in productive environments).
Post by Tom Shelton
In other words - the end is nigh.
That is true of course, always was - for all of us...;-)
Post by Tom Shelton
Post by Schmidt
And it is "less far" from the current base-tech
(C/C++ and COM) than .NET is - that's my whole point.
...
First off - the runtime is not a thin layer over c/c++.
I didn't wrote that.
Oh - you mean the WinRT (not the VBClassic-Runtime-lib)?
In this case I have to tell you, that the C/C++ guys
are very happy with WinRT, because they can bypass
any "intermediate .NET-layer" (you know, the "bloated
VM" I wrote about earlier <g>), to get access to the
system much more directly.
And of course the WinRT sits atop of C/C++ libs
(currently the classic Win-API on x86-machines) -
but on top of the WinAPI and WinRT comes the consuming
Application-Code, which (if you don't want bloat) should be
written also in C/C++. So, the "thin layer thingy"
works both ways of course...
Here the happy statement of a C++-developer -
http://www.codeproject.com/KB/cpp/WinRTVisualCppIntro.aspx
"...But for faster applications with smaller memory footprints
where performance is the key focal point, using C++ to write
Metro apps is the way to go because when you do that it's
metal on metal! The renaissance is here, finally."
Post by Tom Shelton
You act as if I have some problem with C/C++?
How do you come to this conclusion? I'm pretty
sure, I've done more work (manifested in megabytes
of VBclassic-adapted binaries) in C/C++ than you.
Post by Tom Shelton
I do not. In fact, I love C++.
Then go on, use it - there's even better suited
Newsgroups to talk about your love or C++ and all that.
Post by Tom Shelton
Post by Schmidt
From my point of view, it is you who's living in a
dream world, not acknowledging, that both approaches
(from MS' point of view) were only temporary cash-cows,
sold to "crowds of RAD-believers".
The difference between .NET- and "still VB6"-users is,
that the latter ones recognized "the pattern" much
earlier (fool me once) - and didn't invest that much
time again into "the next distraction".
That is simply the most ridiculous bunch of rubbish
I have ever read. VB6 is simply irrelavent -
If you say so - but again, in the same way as .NET is
becoming more and more irrelevant.
Post by Tom Shelton
and about to fade completely into the foot
notes of history.
In the same way as .NET does.
Post by Tom Shelton
If you can't see that, than you simply aren't paying
attention. Smart tv's, smart camera's, tablets, phones, etc
Yeah, sure.
Smart anything - as well as "i like" or "fast and fluent"
or other marketing-rubbish you apparently are fond of...
Post by Tom Shelton
they are becomming the center of the computing industry.
Prebuilt devices with prebuilt vendor-apps, accompanied
by already saturated "App-markets". That's what the
"new developer-generation" has to struggle with
(to get their feets in).
What remains (for existing small software-companies
and selfemployed devs with a bit of a business-background)
is more or less (still) the branch-applications,
which wants to be run on a normal Desktop, on a
normal PC (with mouse and keyboard).
Post by Tom Shelton
Which, basically means even MS is struggling to stay relavent
right now, against the on slaught of Android/iOS.
And that means, java or C (well, objective-c for ios :)
Glad you admit that.
It's an important point - and BTW the base of my assumption,
that my statement ".NET is becoming more and more irrelevant too"
is becoming a true one.
Post by Tom Shelton
At least, with C# there are tools for targeting android and even ios.
Yes, as I wrote above, the few percent which are left
for MS in this tv/table/phone consumer-market can be addressed
either with C#/VB.NET/C++ or with just simple HTML/JS.
And as said, should I ever be inconvenienced with the
requirement, to write a (probably then accompanying a larger DeskApp)
small application for a tablet or phone-device, then I'd
do it in HTML/JS - since all these platforms come with a
mobile-browser. There's even jQuery-abstraction-classes
for the touch-interface-events for most of them.
Post by Tom Shelton
Haven't seen any for VB6...
As said, not needed - for Desktop-stuff VBClassic is more
than enough - for "fun- and simple consumer-stuff" HTML/JS
should be sufficient too.
Post by Tom Shelton
And, worse case - it's not that difficult to port my C#
libraries to Java (the major programming environment in the
android echo system).
What are these libraries, if I may ask that?
What sense do they make, ported to a small-screen-device?
Aside from that, wouldn't it be better, to leave them
"as is" and just put their functionality at the serverside
and just show the computed (HTML/JSON) results on these small
screens (in a few WebPages), hmm?
You see, why I ask that - do you? Because exactly
the same way is open for any COM-library, written
in VBClassic (to put them into place behind a WebServer).
Post by Tom Shelton
The fact, is the world has moved on and left you behind.
Coming from you I can live with that, I think... ;-)
Olaf
Schmidt
2012-01-13 23:58:33 UTC
Permalink
Post by Henning
Post by Schmidt
BTW, I've recently sold Desktop-Systems, which offered
(at request) both, a TouchScreen-interface and
alternatively "classic input" over Mouse/Keyboard.
What happened after a few weeks of playing around
is, that on my last visit everybody was back
using the Mouse exclusively.
I have the same experience, they used it for a month,
then went back to kb/mouse.
Glad you confirmed that...
But it's logical IMO - first thing is, you usually
*sit* on a Desktop - and there's no convenient way, to
hold one of these larger 21-24" Touchscreens "on your lap"
One has to be standing, to use the touch-interface.
So first there's the "ergonomics" which are at play
here. And then there's of course a whole bunch of
more or less irrational reasoning, as for example:
"I hate those thumbprints on my screen, do I really
have to clean them myself any other day?"
not the least among them. ;-)
Post by Henning
Their expensive touchscreens are only "normal"
monitors today.
Yep, same here - although there are devices which are only
about 100Euro more expensive than their normal counterparts.
I used this model here (the touch worked well enough,
it even came with a small TouchPen-device in the bottom-
right corner):
http://www.alternate.de/html/product/Iiyama/ProLite_T2250MTS-B1/144613/?


Olaf
GS
2012-01-14 00:35:25 UTC
Permalink
Just want to interject that VB will persist to exist as the language of
choice for macros in MS Office. Since MS has reworked VBA to work in
x64 (VBA7), I don't expect VB to disappear in my working lifetime.
While it may be arguable that VBA is not Classic VB in various ways, it
remains that the underlying core to the VBA language IS Classic VB!<g>

MS tried to take away VBA capability it Mac versions of MS Office and
got a horrific reaming for doing so. -Well.., at least enough of a
reaming that they put it back in pretty quick!

I'm thinking there is not a dedicated special runtime for VBA, and so
unless I'm wrong MS will continue to ship that runtime with MS Office
if they take it out of Windows!<IMO>
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc
GS
2012-01-14 03:46:11 UTC
Permalink
Post by GS
Just want to interject that VB will persist to exist as the language of
choice for macros in MS Office. Since MS has reworked VBA to work in x64
(VBA7), I don't expect VB to disappear in my working lifetime. While it may
be arguable that VBA is not Classic VB in various ways, it remains that the
underlying core to the VBA language IS Classic VB!<g>
MS tried to take away VBA capability it Mac versions of MS Office and got a
horrific reaming for doing so. -Well.., at least enough of a reaming that
they put it back in pretty quick!
I'm thinking there is not a dedicated special runtime for VBA, and so unless
I'm wrong MS will continue to ship that runtime with MS Office if they take
it out of Windows!<IMO>
Turns out, I've discovered, that the runtime for VBA IS a separate
runtime and includes several DLLs for the VBE as well. Interesting...
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Tom Shelton
2012-01-14 06:50:48 UTC
Permalink
Post by GS
Just want to interject that VB will persist to exist as the language
of choice for macros in MS Office. Since MS has reworked VBA to work
in x64 (VBA7), I don't expect VB to disappear in my working lifetime.
While it may be arguable that VBA is not Classic VB in various ways,
it remains that the underlying core to the VBA language IS Classic
VB!<g>
MS tried to take away VBA capability it Mac versions of MS Office and
got a horrific reaming for doing so. -Well.., at least enough of a
reaming that they put it back in pretty quick!
I'm thinking there is not a dedicated special runtime for VBA, and so
unless I'm wrong MS will continue to ship that runtime with MS Office
if they take it out of Windows!<IMO>
Not where I work - we use VS tools for office. VBA is banned.
--
Tom Shelton
GS
2012-01-14 19:31:08 UTC
Permalink
Post by Tom Shelton
Post by GS
Just want to interject that VB will persist to exist as the language of
choice for macros in MS Office. Since MS has reworked VBA to work in x64
(VBA7), I don't expect VB to disappear in my working lifetime. While it may
be arguable that VBA is not Classic VB in various ways, it remains that the
underlying core to the VBA language IS Classic VB!<g>
MS tried to take away VBA capability it Mac versions of MS Office and got a
horrific reaming for doing so. -Well.., at least enough of a reaming that
they put it back in pretty quick!
I'm thinking there is not a dedicated special runtime for VBA, and so
unless I'm wrong MS will continue to ship that runtime with MS Office if
they take it out of Windows!<IMO>
Not where I work - we use VS tools for office. VBA is banned.
Yeah, I'm a big fan of using COMAddins over VBA. Though, I suppose the
.Net tools aren't really COM in the same way anymore. C++ is my choice
tool now but I'll use C# if .Net is really necessary. The nice thing
about C++ is that it still lets me use my 3rd party ActiveX components
that also work with VB6/VBA projects.<g>
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Tom Shelton
2012-01-15 05:47:25 UTC
Permalink
Post by GS
Post by Tom Shelton
Post by GS
Just want to interject that VB will persist to exist as the
language of choice for macros in MS Office. Since MS has reworked
VBA to work in x64 (VBA7), I don't expect VB to disappear in my
working lifetime. While it may be arguable that VBA is not Classic
VB in various ways, it remains that the underlying core to the VBA
language IS Classic VB!<g>
MS tried to take away VBA capability it Mac versions of MS Office
and got a horrific reaming for doing so. -Well.., at least enough
of a reaming that they put it back in pretty quick!
I'm thinking there is not a dedicated special runtime for VBA, and
so unless I'm wrong MS will continue to ship that runtime with MS
Office if they take it out of Windows!<IMO>
Not where I work - we use VS tools for office. VBA is banned.
Yeah, I'm a big fan of using COMAddins over VBA. Though, I suppose
the .Net tools aren't really COM in the same way anymore. C++ is my
choice tool now but I'll use C# if .Net is really necessary. The nice
thing about C++ is that it still lets me use my 3rd party ActiveX
components that also work with VB6/VBA projects.<g>
And you can use them in .NET as well... COM IS part of .NET.
--
Tom Shelton
GS
2012-01-15 06:26:49 UTC
Permalink
Post by Tom Shelton
Post by Tom Shelton
Post by GS
Just want to interject that VB will persist to exist as the language of
choice for macros in MS Office. Since MS has reworked VBA to work in x64
(VBA7), I don't expect VB to disappear in my working lifetime. While it
may be arguable that VBA is not Classic VB in various ways, it remains
that the underlying core to the VBA language IS Classic VB!<g>
MS tried to take away VBA capability it Mac versions of MS Office and got
a horrific reaming for doing so. -Well.., at least enough of a reaming
that they put it back in pretty quick!
I'm thinking there is not a dedicated special runtime for VBA, and so
unless I'm wrong MS will continue to ship that runtime with MS Office if
they take it out of Windows!<IMO>
Not where I work - we use VS tools for office. VBA is banned.
Yeah, I'm a big fan of using COMAddins over VBA. Though, I suppose the .Net
tools aren't really COM in the same way anymore. C++ is my choice tool now
but I'll use C# if .Net is really necessary. The nice thing about C++ is
that it still lets me use my 3rd party ActiveX components that also work
with VB6/VBA projects.<g>
And you can use them in .NET as well... COM IS part of .NET.
Not according to the manufacturer[s]. They recommend upgrading to their
.net versions. Has something to do with Windows Forms. If you can point
me to some info regarding using ActiveX components (in my case .OCXs)
I'd appreciate that very much.
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Tom Shelton
2012-01-15 14:54:08 UTC
Permalink
Post by GS
Post by Tom Shelton
Post by GS
Post by Tom Shelton
Post by GS
Just want to interject that VB will persist to exist as the
language of choice for macros in MS Office. Since MS has
reworked VBA to work in x64 (VBA7), I don't expect VB to
disappear in my working lifetime. While it may be arguable that
VBA is not Classic VB in various ways, it remains that the
underlying core to the VBA language IS Classic VB!<g>
MS tried to take away VBA capability it Mac versions of MS
Office and got a horrific reaming for doing so. -Well.., at
least enough of a reaming that they put it back in pretty quick!
I'm thinking there is not a dedicated special runtime for VBA,
and so unless I'm wrong MS will continue to ship that runtime
with MS Office if they take it out of Windows!<IMO>
Not where I work - we use VS tools for office. VBA is banned.
Yeah, I'm a big fan of using COMAddins over VBA. Though, I suppose
the .Net tools aren't really COM in the same way anymore. C++ is
my choice tool now but I'll use C# if .Net is really necessary.
The nice thing about C++ is that it still lets me use my 3rd party
ActiveX components that also work with VB6/VBA projects.<g>
And you can use them in .NET as well... COM IS part of .NET.
Not according to the manufacturer[s]. They recommend upgrading to
their .net versions. Has something to do with Windows Forms. If you
can point me to some info regarding using ActiveX components (in my
case .OCXs) I'd appreciate that very much.
I've used AX components before... Simply add them to your toolbox - on
the COM tab, and drag and drop them on the form. So, either the
manufacturer[s] have done something really stupid (can't think what,
because I haven't found one that didn't work - though, you might need
to change your compile target to x86) or they are lying.
--
Tom Shelton
GS
2012-01-15 19:09:30 UTC
Permalink
Post by GS
Post by Tom Shelton
Post by GS
Post by Tom Shelton
Post by GS
Just want to interject that VB will persist to exist as the language of
choice for macros in MS Office. Since MS has reworked VBA to work in
x64 (VBA7), I don't expect VB to disappear in my working lifetime.
While it may be arguable that VBA is not Classic VB in various ways, it
remains that the underlying core to the VBA language IS Classic VB!<g>
MS tried to take away VBA capability it Mac versions of MS Office and
got a horrific reaming for doing so. -Well.., at least enough of a
reaming that they put it back in pretty quick!
I'm thinking there is not a dedicated special runtime for VBA, and so
unless I'm wrong MS will continue to ship that runtime with MS Office
if they take it out of Windows!<IMO>
Not where I work - we use VS tools for office. VBA is banned.
Yeah, I'm a big fan of using COMAddins over VBA. Though, I suppose the
.Net tools aren't really COM in the same way anymore. C++ is my choice
tool now but I'll use C# if .Net is really necessary. The nice thing
about C++ is that it still lets me use my 3rd party ActiveX components
that also work with VB6/VBA projects.<g>
And you can use them in .NET as well... COM IS part of .NET.
Not according to the manufacturer[s]. They recommend upgrading to their
.net versions. Has something to do with Windows Forms. If you can point me
to some info regarding using ActiveX components (in my case .OCXs) I'd
appreciate that very much.
I've used AX components before... Simply add them to your toolbox - on the
COM tab, and drag and drop them on the form. So, either the manufacturer[s]
have done something really stupid (can't think what, because I haven't found
one that didn't work - though, you might need to change your compile target
to x86) or they are lying.
I'm thinking they just want to sell more product. I'll certainly try
your suggestion in C#. Big thanks...
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Tom Shelton
2012-01-15 23:47:56 UTC
Permalink
Post by GS
Post by Tom Shelton
Post by GS
Post by Tom Shelton
Post by GS
Post by Tom Shelton
Post by GS
Just want to interject that VB will persist to exist as the
language of choice for macros in MS Office. Since MS has
reworked VBA to work in x64 (VBA7), I don't expect VB to
disappear in my working lifetime. While it may be arguable
that VBA is not Classic VB in various ways, it remains that
the underlying core to the VBA language IS Classic VB!<g>
MS tried to take away VBA capability it Mac versions of MS
Office and got a horrific reaming for doing so. -Well.., at
least enough of a reaming that they put it back in pretty quick!
I'm thinking there is not a dedicated special runtime for VBA,
and so unless I'm wrong MS will continue to ship that runtime
with MS Office if they take it out of Windows!<IMO>
Not where I work - we use VS tools for office. VBA is banned.
Yeah, I'm a big fan of using COMAddins over VBA. Though, I
suppose the .Net tools aren't really COM in the same way
anymore. C++ is my choice tool now but I'll use C# if .Net is
really necessary. The nice thing about C++ is that it still lets
me use my 3rd party ActiveX components that also work with
VB6/VBA projects.<g>
And you can use them in .NET as well... COM IS part of .NET.
Not according to the manufacturer[s]. They recommend upgrading to
their .net versions. Has something to do with Windows Forms. If
you can point me to some info regarding using ActiveX components
(in my case .OCXs) I'd appreciate that very much.
I've used AX components before... Simply add them to your toolbox
- on the COM tab, and drag and drop them on the form. So, either
the manufacturer[s] have done something really stupid (can't think
what, because I haven't found one that didn't work - though, you
might need to change your compile target to x86) or they are lying.
I'm thinking they just want to sell more product. I'll certainly try
your suggestion in C#. Big thanks...
Well, my guess is that they will work - but, I probably shouldn't have
been so terse in my response. There is always a possiblity that a
particular that something might go wrong in a new environment :)
--
Tom Shelton
Tom Shelton
2012-01-15 23:49:45 UTC
Permalink
Post by Tom Shelton
Post by GS
Post by Tom Shelton
Post by GS
Post by Tom Shelton
Post by GS
Post by Tom Shelton
Post by GS
Just want to interject that VB will persist to exist as the
language of choice for macros in MS Office. Since MS has
reworked VBA to work in x64 (VBA7), I don't expect VB to
disappear in my working lifetime. While it may be arguable
that VBA is not Classic VB in various ways, it remains that
the underlying core to the VBA language IS Classic VB!<g>
MS tried to take away VBA capability it Mac versions of MS
Office and got a horrific reaming for doing so. -Well.., at
least enough of a reaming that they put it back in pretty quick!
I'm thinking there is not a dedicated special runtime for
VBA, and so unless I'm wrong MS will continue to ship that
runtime with MS Office if they take it out of Windows!<IMO>
Not where I work - we use VS tools for office. VBA is
banned.
Yeah, I'm a big fan of using COMAddins over VBA. Though, I
suppose the .Net tools aren't really COM in the same way
anymore. C++ is my choice tool now but I'll use C# if .Net is
really necessary. The nice thing about C++ is that it still
lets me use my 3rd party ActiveX components that also work with
VB6/VBA projects.<g>
And you can use them in .NET as well... COM IS part of .NET.
Not according to the manufacturer[s]. They recommend upgrading to
their .net versions. Has something to do with Windows Forms. If
you can point me to some info regarding using ActiveX components
(in my case .OCXs) I'd appreciate that very much.
I've used AX components before... Simply add them to your toolbox
- on the COM tab, and drag and drop them on the form. So, either
the manufacturer[s] have done something really stupid (can't think
what, because I haven't found one that didn't work - though, you
might need to change your compile target to x86) or they are
lying.
I'm thinking they just want to sell more product. I'll certainly
try your suggestion in C#. Big thanks...
Well, my guess is that they will work - but, I probably shouldn't
have been so terse in my response. There is always a possiblity that
a particular that something might go wrong in a new environment :)
Wow... mangled that :) I was trying to say there is always a
possiblility of failure in a new envrionment - but, I must have been
thinking two sentences at a time.... :)
--
Tom Shelton
GS
2012-01-16 02:16:36 UTC
Permalink
Ok, I tried this and it's definitely a no-go. Not saying it's still not
doable, but rather a quick check didn't work for each of 3 components.
Looks like the C# environment doesn't like them, though. I'll try C++
when I get time...
--
Garry

Free usenet access at http://www.eternal-september.org
ClassicVB Users Regroup! comp.lang.basic.visual.misc
Loading...