Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.basic.visual.misc > #601 > unrolled thread

Upgrading older VB programs (sans Project Files) to VB.NET

Back to article view | Back to comp.lang.basic.visual.misc

Contents

  Upgrading older VB programs (sans Project Files) to VB.NET Ubiquitous <weberm@polaris.net> - 2012-01-04 18:23 -0500
    Re: Upgrading older VB programs (sans Project Files) to VB.NET "Mayayana" <mayayana@invalid.nospam> - 2012-01-05 09:25 -0500
    Re: Upgrading older VB programs (sans Project Files) to VB.NET "Thorsten Albers" <gudea@gmx.de> - 2012-01-05 16:33 +0000
    Re: Upgrading older VB programs (sans Project Files) to VB.NET GS <gs@somewhere.net> - 2012-01-05 14:57 -0500
    Re: Upgrading older VB programs (sans Project Files) to VB.NET Helmut_Meukel <Helmut_Meukel@bn-hof.invalid> - 2012-01-05 22:32 +0100
      Re: Upgrading older VB programs (sans Project Files) to VB.NET "Auric__" <not.my.real@email.address> - 2012-01-06 02:50 +0000
    Re: Upgrading older VB programs (sans Project Files) to VB.NET Tony Toews <ttoews@telusplanet.net> - 2012-01-09 20:29 -0700
      Re: Upgrading older VB programs (sans Project Files) to VB.NET "Mayayana" <mayayana@invalid.nospam> - 2012-01-10 09:22 -0500
        Re: Upgrading older VB programs (sans Project Files) to VB.NET Tom Shelton <tom_shelton@comcast.invalid> - 2012-01-10 10:14 -0700
          Re: Upgrading older VB programs (sans Project Files) to VB.NET "Mayayana" <mayayana@invalid.nospam> - 2012-01-10 17:04 -0500
          Re: Upgrading older VB programs (sans Project Files) to VB.NET Schmidt <sss@online.de> - 2012-01-11 21:02 +0100
            Re: Upgrading older VB programs (sans Project Files) to VB.NET "Henning" <computer_hero@coldmail.com> - 2012-01-12 15:33 +0100
              Re: Upgrading older VB programs (sans Project Files) to VB.NET GS <gs@somewhere.net> - 2012-01-12 23:58 -0500
            Re: Upgrading older VB programs (sans Project Files) to VB.NET Tom Shelton <tom_shelton@comcast.invalid> - 2012-01-12 09:34 -0700
              Re: Upgrading older VB programs (sans Project Files) to VB.NET Schmidt <sss@online.de> - 2012-01-13 20:17 +0100
                Re: Upgrading older VB programs (sans Project Files) to VB.NET GS <gs@somewhere.net> - 2012-01-13 14:31 -0500
                Re: Upgrading older VB programs (sans Project Files) to VB.NET Tom Shelton <tom_shelton@comcast.invalid> - 2012-01-13 13:22 -0700
                  Re: Upgrading older VB programs (sans Project Files) to VB.NET "Mayayana" <mayayana@invalid.nospam> - 2012-01-13 16:07 -0500
                    Re: Upgrading older VB programs (sans Project Files) to VB.NET Tom Shelton <tom_shelton@comcast.invalid> - 2012-01-13 14:14 -0700
                      Re: Upgrading older VB programs (sans Project Files) to VB.NET "Mayayana" <mayayana@invalid.nospam> - 2012-01-13 20:58 -0500
                        Re: Upgrading older VB programs (sans Project Files) to VB.NET Tony Toews <ttoews@telusplanet.net> - 2012-01-19 19:10 -0700
                  Re: Upgrading older VB programs (sans Project Files) to VB.NET Schmidt <sss@online.de> - 2012-01-14 00:12 +0100
                    Re: Upgrading older VB programs (sans Project Files) to VB.NET "Henning" <computer_hero@coldmail.com> - 2012-01-14 00:24 +0100
                      Re: Upgrading older VB programs (sans Project Files) to VB.NET Schmidt <sss@online.de> - 2012-01-14 00:58 +0100
                Re: Upgrading older VB programs (sans Project Files) to VB.NET GS <gs@somewhere.net> - 2012-01-13 19:35 -0500
                  Re: Upgrading older VB programs (sans Project Files) to VB.NET GS <gs@somewhere.net> - 2012-01-13 22:46 -0500
                  Re: Upgrading older VB programs (sans Project Files) to VB.NET Tom Shelton <tom_shelton@comcast.invalid> - 2012-01-13 23:50 -0700
                    Re: Upgrading older VB programs (sans Project Files) to VB.NET GS <gs@somewhere.net> - 2012-01-14 14:31 -0500
                      Re: Upgrading older VB programs (sans Project Files) to VB.NET Tom Shelton <tom_shelton@comcast.invalid> - 2012-01-14 22:47 -0700
                        Re: Upgrading older VB programs (sans Project Files) to VB.NET GS <gs@somewhere.net> - 2012-01-15 01:26 -0500
                          Re: Upgrading older VB programs (sans Project Files) to VB.NET Tom Shelton <tom_shelton@comcast.invalid> - 2012-01-15 07:54 -0700
                            Re: Upgrading older VB programs (sans Project Files) to VB.NET GS <gs@somewhere.net> - 2012-01-15 14:09 -0500
                              Re: Upgrading older VB programs (sans Project Files) to VB.NET Tom Shelton <tom_shelton@comcast.invalid> - 2012-01-15 16:47 -0700
                                Re: Upgrading older VB programs (sans Project Files) to VB.NET Tom Shelton <tom_shelton@comcast.invalid> - 2012-01-15 16:49 -0700
                                  Re: Upgrading older VB programs (sans Project Files) to VB.NET GS <gs@somewhere.net> - 2012-01-15 21:16 -0500

Page 2 of 2 — ← Prev page 1 [2]

#706

On Fri, 13 Jan 2012 20:58:12 -0500, "Mayayana"
<mayayana@invalid.nospam> wrote:
  
>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.

>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/

[toc] | [prev] | [next] | [standalone]

#651

Am 13.01.2012 21:22, schrieb Tom Shelton:

>> 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.

> 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).


> 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>


>> 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.


> 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.


> 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).

> In other words - the end is nigh.

That is true of course, always was - for all of us...;-)


>> 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."

> 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.

> 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.

>> 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.

> and about to fade completely into the foot
> notes of history.
In the same way as .NET does.

> 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...

> 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).

> 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.


> 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.

> 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.

> 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).

> The fact, is the world has moved on and left you behind.
Coming from you I can live with that, I think... ;-)


Olaf

[toc] | [prev] | [next] | [standalone]

#652

"Schmidt" <sss@online.de> skrev i meddelandet 
news:jeqdot$gs8$1@dont-email.me...
> Am 13.01.2012 21:22, schrieb Tom Shelton:
>
>>> 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.
>
>> 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.

>
> 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).
>
>
>> 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>
>
>
>>> 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.
>
>
>> 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.
>
>
>> 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).
>
>> In other words - the end is nigh.
>
> That is true of course, always was - for all of us...;-)
>
>
>>> 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."
>
>> 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.
>
>> 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.
>
>>> 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.
>
>> and about to fade completely into the foot
>> notes of history.
> In the same way as .NET does.
>
>> 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...
>
>> 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).
>
>> 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.
>
>
>> 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.
>
>> 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.
>
>> 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).
>
>> The fact, is the world has moved on and left you behind.
> Coming from you I can live with that, I think... ;-)
>
>
> Olaf 

[toc] | [prev] | [next] | [standalone]

#653

Am 14.01.2012 00:24, schrieb Henning:

>> 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. ;-)

 > 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

[toc] | [prev] | [next] | [standalone]

#654

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

[toc] | [prev] | [next] | [standalone]

#656

GS explained :
> 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

[toc] | [prev] | [next] | [standalone]

#657

GS pretended :
> 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

[toc] | [prev] | [next] | [standalone]

#665

Tom Shelton formulated on Saturday :
> GS pretended :
>> 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

[toc] | [prev] | [next] | [standalone]

#666

GS used his keyboard to write :
> Tom Shelton formulated on Saturday :
>> GS pretended :
>>> 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

[toc] | [prev] | [next] | [standalone]

#667

Tom Shelton explained on 1/15/2012 :
> GS used his keyboard to write :
>> Tom Shelton formulated on Saturday :
>>> GS pretended :
>>>> 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

[toc] | [prev] | [next] | [standalone]

#669

GS explained :
> Tom Shelton explained on 1/15/2012 :
>> GS used his keyboard to write :
>>> Tom Shelton formulated on Saturday :
>>>> GS pretended :
>>>>> 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

[toc] | [prev] | [next] | [standalone]

#671

Tom Shelton submitted this idea :
> GS explained :
>> Tom Shelton explained on 1/15/2012 :
>>> GS used his keyboard to write :
>>>> Tom Shelton formulated on Saturday :
>>>>> GS pretended :
>>>>>> 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

[toc] | [prev] | [next] | [standalone]

#675

GS formulated on Sunday :
> Tom Shelton submitted this idea :
>> GS explained :
>>> Tom Shelton explained on 1/15/2012 :
>>>> GS used his keyboard to write :
>>>>> Tom Shelton formulated on Saturday :
>>>>>> GS pretended :
>>>>>>> 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

[toc] | [prev] | [next] | [standalone]

#676

Tom Shelton has brought this to us :
> GS formulated on Sunday :
>> Tom Shelton submitted this idea :
>>> GS explained :
>>>> Tom Shelton explained on 1/15/2012 :
>>>>> GS used his keyboard to write :
>>>>>> Tom Shelton formulated on Saturday :
>>>>>>> GS pretended :
>>>>>>>> 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

[toc] | [prev] | [next] | [standalone]

#677

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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.basic.visual.misc

csiph-web