Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.basic.visual.misc > #1080 > unrolled thread
| Started by | Sandwich <liam.whan@gmail.com> |
|---|---|
| First post | 2012-05-19 22:10 -0700 |
| Last post | 2012-05-30 06:51 +0100 |
| Articles | 20 on this page of 65 — 13 participants |
Back to article view | Back to comp.lang.basic.visual.misc
VB.net (2010) Beginner Question: Directory Lists Sandwich <liam.whan@gmail.com> - 2012-05-19 22:10 -0700
Re: VB.net (2010) Beginner Question: Directory Lists "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-05-20 10:24 +0100
Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-20 09:41 -0400
Re: VB.net (2010) Beginner Question: Directory Lists "Auric__" <not.my.real@email.address> - 2012-05-20 19:27 +0000
Re: VB.net (2010) Beginner Question: Directory Lists Sandwich <liam.whan@gmail.com> - 2012-05-20 19:06 -0700
Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-20 23:32 -0400
Re: VB.net (2010) Beginner Question: Directory Lists Sandwich <liam.whan@gmail.com> - 2012-05-20 22:05 -0700
Re: VB.net (2010) Beginner Question: Directory Lists Gordon Levi <gordon@address.invalid> - 2012-05-23 01:37 +1000
Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-22 13:24 -0400
Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-22 11:30 -0600
Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-22 14:03 -0400
Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-22 12:15 -0600
Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-22 15:05 -0400
Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-22 14:01 -0600
Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-22 17:29 -0400
Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-22 17:13 -0600
Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-23 09:10 -0400
Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-23 10:24 -0600
Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-22 14:37 -0600
Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-25 10:55 -0400
Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-22 14:38 -0400
Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-22 12:47 -0600
Re: VB.net (2010) Beginner Question: Directory Lists Gordon Levi <gordon@address.invalid> - 2012-05-24 23:44 +1000
Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-24 10:07 -0400
Re: VB.net (2010) Beginner Question: Directory Lists "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-05-24 16:07 +0100
Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-24 09:57 -0600
Re: VB.net (2010) Beginner Question: Directory Lists Gordon Levi <gordon@address.invalid> - 2012-05-25 18:39 +1000
Re: VB.net (2010) Beginner Question: Directory Lists "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-05-25 11:23 +0100
Re: VB.net (2010) Beginner Question: Directory Lists Gordon Levi <gordon@address.invalid> - 2012-05-27 23:07 +1000
Re: VB.net (2010) Beginner Question: Directory Lists "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-05-27 16:44 +0100
Re: VB.net (2010) Beginner Question: Directory Lists ralph <nt_consulting64@yahoo.com> - 2012-05-27 17:12 -0500
Re: VB.net (2010) Beginner Question: Directory Lists "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-05-30 07:04 +0100
Re: VB.net (2010) Beginner Question: Directory Lists ralph <nt_consulting64@yahoo.com> - 2012-05-30 02:36 -0500
Re: VB.net (2010) Beginner Question: Directory Lists "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-05-31 08:54 +0100
Re: VB.net (2010) Beginner Question: Directory Lists ralph <nt_consulting64@yahoo.com> - 2012-05-31 10:33 -0500
Re: VB.net (2010) Beginner Question: Directory Lists Gordon Levi <gordon@address.invalid> - 2012-05-30 23:19 +1000
Re: VB.net (2010) Beginner Question: Directory Lists ralph <nt_consulting64@yahoo.com> - 2012-05-30 14:09 -0500
Re: VB.net (2010) Beginner Question: Directory Lists GS <gs@somewhere.net> - 2012-05-25 13:44 -0400
Re: VB.net (2010) Beginner Question: Directory Lists -mhd <not_real@invalid.com> - 2012-05-25 17:47 -0400
Re: VB.net (2010) Beginner Question: Directory Lists GS <gs@somewhere.net> - 2012-05-25 19:51 -0400
Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-22 11:09 -0600
Re: VB.net (2010) Beginner Question: Directory Lists "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-05-23 13:07 +0100
Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-23 10:14 -0600
Re: VB.net (2010) Beginner Question: Directory Lists Schmidt <sss@online.de> - 2012-05-24 20:38 +0200
Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-24 15:46 -0600
Re: VB.net (2010) Beginner Question: Directory Lists "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-05-25 06:52 +0100
Re: VB.net (2010) Beginner Question: Directory Lists Schmidt <sss@online.de> - 2012-05-25 11:14 +0200
Re: VB.net (2010) Beginner Question: Directory Lists "DaveO" <djo@dial.pipex.com> - 2012-05-25 10:57 +0100
Re: VB.net (2010) Beginner Question: Directory Lists Schmidt <sss@online.de> - 2012-05-25 13:36 +0200
Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-25 09:25 -0400
Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-25 10:12 -0600
Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-25 12:27 -0400
Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-25 14:22 -0600
Re: VB.net (2010) Beginner Question: Directory Lists Schmidt <sss@online.de> - 2012-05-26 18:38 +0200
Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-26 14:12 -0600
Re: VB.net (2010) Beginner Question: Directory Lists "Henning" <computer_hero@coldmail.com> - 2012-05-26 23:31 +0200
Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-26 18:07 -0400
Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-26 16:50 -0600
Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-26 20:53 -0400
Re: VB.net (2010) Beginner Question: Directory Lists Tom Shelton <tom_shelton@comcast.invalid> - 2012-05-26 20:31 -0600
Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-27 09:49 -0400
Re: VB.net (2010) Beginner Question: Directory Lists Karl E. Peterson <karl@exmvps.org> - 2012-05-29 12:50 -0700
Re: VB.net (2010) Beginner Question: Directory Lists "Mayayana" <mayayana@invalid.nospam> - 2012-05-29 19:14 -0400
Re: VB.net (2010) Beginner Question: Directory Lists ralph <nt_consulting64@yahoo.com> - 2012-05-29 18:25 -0500
Re: VB.net (2010) Beginner Question: Directory Lists "Mike Williams" <Mike@WhiskyAndCoke.com> - 2012-05-30 06:51 +0100
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Tom Shelton <tom_shelton@comcast.invalid> |
|---|---|
| Date | 2012-05-22 11:09 -0600 |
| Message-ID | <jpgh91$7at$1@dont-email.me> |
| In reply to | #1084 |
Sandwich brought next idea :
> On May 21, 5:27 am, "Auric__" <not.my.r...@email.address> wrote:
>> Sandwich wrote:
>>
>> [snip]
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> I have been able to find the followingwith endless searching
>>> [code]
>>> ' make a reference to a directory
>>> Dim di As New IO.DirectoryInfo("c:\")
>>> Dim diar1 As IO.FileInfo() = di.GetFiles()
>>> Dim dra As IO.FileInfo
>>
>>> 'list the names of all files in the specified directory
>>> For Each dra In diar1
>>> ListBox1.Items.Add(dra)
>>> Next
>>> [/code]
>>
>>> Thsi obviously gives me a string array of the file addresses and
>>> names;
>>
>>> how can I now filter out the address and extension text and just
>>> display the word?
>>
>> On the one hand, your problem is trivially easy, and there are
>> several ways to go about doing what you need. Any place you need
>> just the filename of "dra", I think I would use something like this:
>> dra.Name.Substring(0, dra.Name.IndexOf("."))
>>
>> So, if you wanted to load your listbox with the filenames, you could
>> do this:
>> ListBox1.Items.Add(dra.Name.Substring(0, dra.Name.IndexOf(".")))
>>
>> On the other hand, I agree with Mike and Mayayana: this is not a
>> .Net group. I *especially* agree with Mayayana about the unnecessary
>> bloat and BS that .Net requires. Instead of scripting, which he
>> discusses a bit, I just switched to a different language entirely,
>> FreeBASIC: http://www.freebasic.net/
>> Based on, and almost 100% compatible with, QuickBASIC (MS's old DOS
>> compiler), with the added advantage of being completely free.
>>
>> Alternately, there are many, many other BASICs that work with
>> Windows and are much less bloated than VB.Net. I suggest PowerBASIC,
>> REAL Studio, or Liberty Basic.
>> - PowerBASIC is my overall favorite BASIC (but I don't use it much
>> because I program for Linux, which PB doesn't support -- and windows
>> are a bit more difficult):
>> http://www.powerbasic.com/
>> - REAL Studio is somewhat VB-like and has probably the best support
>> for windows (forms) outside of Microsoft's products:
>> http://www.realsoftware.com/
>> - Liberty Basic is *very* easy to learn, but compiles to bytecode
>> rather than machine code (not really a problem, but something to be
>> aware of): http://www.libertybasic.com/
>>
>> --
>> I want to be cremated, and I want my ashes blown in Uri Geller's
>> eyes. -- James Randi (skeptic)
>
> Wow,
>
> thankyou all for taking the time to respond so quickly and
> completely, and apologies for posting a heretic .NET question in
> here, as a new hobbyist programmer it was ignorance rather than
> malice!
>
> BTW you've convinced me to switch. I chose VB.net as I'm a new
> programmer and the temptation is to think that you might as well
> learn the most current imprint of the language.
If you plan on having a future programming in a windows environment, I
would ignore these chumps. VB6 is dead, dead, dead.
Personally, I wouldn't waste my time with ANY VB flavor. C# would
actually give you many more options - there are even products that let
you create apps for iPhones and Android using C#. And, if you need to
- the syntax is similar to C++ - should you ever want to get a little
closer to the metal.
So, here is the real story - sure, vb6 apps should mostly continue to
work on Windows 8. But, I wouldn't get your hopes up beyond that.
Futher, using VB.CLASSIC is simply going to limit your options in the
windows environment (since you are using VB, I'm going to assume you
don't care about all of the other environments). You won't be able to
write 64-bit apps. You won't be able to write apps that target the
metro interface. You won't be able to deploy apps to WinRT at all (arm
version of windows 8) - basically, that rules out tablets and phones
for the most part. You won't be able to market your apps through the
windows market place, etc, etc. Not to mention that fact that VB.NET
is probably orders of magnitude more powerfull and versitile than
VB.CLASSIC. VB.NET is:
1) Fully OOP
2) Extensive and easy to use built in class library...
3) threading, multi-processor support, and async programming
4) linq (linq is the bomb!)
5) lambda support
6) way better support for calling external native api's - examples:
cdecl support, union support, native unicode api support, full support
for data alignment in structures passed to external api's.
etc, etc, etc.
Yes, VB.NET is probably a bit harder to learn than VB.CLASSIC. But,
not by much. The thing is the basic stuff is just as easy, and some
cases easier in VB.NET - and it makes the hard stuff more accessilbe
(multi-threading, mulit-processing, etc - is doable in VB6, for example
- but, it is much harder task to implement correctly in VB6).
Now, for runtime support...
If you are targeting windows, there are very few boxes that do not have
at least the .NET 2.0 runtime. So, targeting 2.0 - you can change your
build target in the project properties in VS - would cover probably
95% of users without them having to install a thing. Vista shipped
with the 3.0 runtime and windows 7 ships with 3.5 - all of these are
really the 2.0 runtime with some additional libraries on top. 4.0 is
still a bit rarer, but, you can minimize the size of the runtime
download and install quite a bit by simply targeting the 4.0 client
runtime. And, to be honest - I would suggest you target 4.0 because of
the many advanced features it puts at your disposal.
I will refrain from posting any specific code to this group - even
though the charter for comp.lang.basic.visual.misc specifically says it
is for all versions of VB. I'm sure this post is already going to
upset the gaggle of luddites that inhabit these environs enough
already. If you would like help on your specific problem using VB.NET
or my personal favorite C# - take your question over to the vb.net news
group and I will show you just how easy-peasy your problem is solved
using a fully featured modern programming enviroment.
--
Tom Shelton
[toc] | [prev] | [next] | [standalone]
| From | "Mike Williams" <Mike@WhiskyAndCoke.com> |
|---|---|
| Date | 2012-05-23 13:07 +0100 |
| Message-ID | <jpijth$h17$1@dont-email.me> |
| In reply to | #1091 |
"Tom Shelton" <tom_shelton@comcast.invalid> wrote in message news:jpgh91$7at$1@dont-email.me... > If you plan on having a future programming in a windows > environment, I would ignore these chumps. VB6 is dead, > dead, dead. . . . and so is Windows as far as the consumers who spend most of the money are concerned. If you're planning on having a future in programming then move away from Windows, period!
[toc] | [prev] | [next] | [standalone]
| From | Tom Shelton <tom_shelton@comcast.invalid> |
|---|---|
| Date | 2012-05-23 10:14 -0600 |
| Message-ID | <jpj2cv$cq5$1@dont-email.me> |
| In reply to | #1103 |
Mike Williams explained on 5/23/2012 : > "Tom Shelton" <tom_shelton@comcast.invalid> wrote in message > news:jpgh91$7at$1@dont-email.me... > >> If you plan on having a future programming in a windows >> environment, I would ignore these chumps. VB6 is dead, >> dead, dead. > > . . . and so is Windows as far as the consumers who spend most of the > money are concerned. If you're planning on having a future in > programming then move away from Windows, period! LOL... I don't fully disagree with this response actually :) -- Tom Shelton
[toc] | [prev] | [next] | [standalone]
| From | Schmidt <sss@online.de> |
|---|---|
| Date | 2012-05-24 20:38 +0200 |
| Message-ID | <jplv7n$e8p$1@speranza.aioe.org> |
| In reply to | #1105 |
Am 23.05.2012 18:14, schrieb Tom Shelton:
> Mike Williams explained on 5/23/2012 :
>> "Tom Shelton" <tom_shelton@comcast.invalid> wrote in message
>> news:jpgh91$7at$1@dont-email.me...
>>
>>> If you plan on having a future programming in a windows
>>> environment, I would ignore these chumps. VB6 is dead,
>>> dead, dead.
>>
>> . . . and so is Windows as far as the consumers who spend most of the
>> money are concerned. If you're planning on having a future in
>> programming then move away from Windows, period!
>
> LOL... I don't fully disagree with this response actually :)
>
Well, then why this recommendation to use ".NET instead"
(which is definitely not that beginner-friendly as VB.Classic)?
When we "all agree" that Windows has no future (in the
context of "classically compiled Desktop-apps) - then I think,
that it is highly probable, that VB.Classic-compiled Binaries
will perhaps have an equal timespan compared with .NET-Assemblies,
as long as we talk about Operating-Systems, which will support
such "real, full-featured Desktop-Apps".
So, as I see it, the OP has to decide (or ask the customer
again), if the planned App in question shall be working on
current Desktop-Machines (from XP, over Vista/Win7 up to Win8) -
and the timespan which covers those machines and their usual
"Office-environment-OS" from current reality (XP) up to
Win8 Desktop-Installations is more than 5 years from now.
If Tablet-Usage is *not* planned for this Application -
and if there's *no* hint currently, that the App in question
needs to "go online" or needs to be "run in a Browser",
then implementing such a "pure Desktop-App" in VB.Classic
would be the least trouble for somebody like the OP (IMO).
It would be in no way "less future-proof", compared with
a .NET-2.0 App (your recommendation) which is using WinForms.
So why exactly should the OP not use VB-Classic for such
a Desktop-Application?
- "Fully OOP" is questionable for a beginner, who will
perhaps not even use Classes or the Implements-Keyword
in VB6... and the inheritance concept *is* by no means
something like a "holy grail".
- Threading is questionable as well, having a beginner in mind
(although VB6 supports that quite well, as you know).
- same thing for your "extensive and easy to use built in
class library..." These deep nested class-hierarchies are:
Not.Exactly.Beginner.Friendly(In->My.Opinion)
(checking in a COM-Dll or an OCX with a simple MouseClick
in the VB6-IDE can do the job as well as far as libs are
concerned, and in VB6 the developer can decide himself about
the "amount of dependencies" the App gets distributed with)
- same thing for throwing linq at a beginner, who's
perhaps not even "fluent" in "applying simple SQL"
(against a classic and simple Desktop-DB) for his
"set-based sort- and filter-operations".
- same thing for "lambda-support"
(would be nice BTW, if you could give a useful example,
I'm pretty sure, a (functionally) equivalent result in VB6
will not consume much more lines of code, and the resulting
VB6-Code will be easier to understand as well...
So what it boils down to, is the original question of
the OP, who wants to put a simple GUI-App together
(applying filters to a list, which in turn hands
out the correct "Video-Path" which then gets set as
the File-input to a simply "plugged in" WMP-Control)...
not exactly rocket-science if you ask me - and since
it is planned, to already make use of the WMP-Control,
then VB6 is the perfect "glueing-language" for such
COMponents.
Also with regards to "lines of code" and "easy deployment",
paired with an uncomplicated, fast and comparatively small
(unbloated) IDE, VB6 is IMO the best choice for a beginner
with some (Quick-)Basic background.
Also his:
"I'm writing this software for deloyment on workstations
that are connected to a pretty tightly controlled Gov network"
reads like that this is indeed planned as a "normal Desktop-
App" ... perhaps rolled out to the greater part to XP-
installations (on the workstations in question), which
definitely come with a preinstalled VB6-runtime (.NET 2.0
is by no means "a given" on XP) - and also very likely with
a preinstalled Windows-Media-Player-COM-lib (the thingy,
named wmp.dll in \System32\ or \SysWOW64\ in Win7-64).
IMO he didn't ask "I'm planning a long-term programming-
career, what language or platform is the most recommendable
in terms of "available jobs" or its "future-proofness".
If that would have been asked, then my answer would be:
C++ paired with wxWidgets or QT
Java
... and nowadays barely a mistake: ...
HTML5/JS + jQuery at the client- (browser-)side, paired
with one of the many (Web-)server-side platforms/languages
(as Rails or PHP or Web2Py or Java or Node.js).
But IMO he asked about a tool, able to "get the job
done", in a reasonable (more or less short) time, and
as long as there's a "classically compiled Desktop-App"
the customer wants, then VB6 is a reasonable, "least
efforts" choice.
Olaf
[toc] | [prev] | [next] | [standalone]
| From | Tom Shelton <tom_shelton@comcast.invalid> |
|---|---|
| Date | 2012-05-24 15:46 -0600 |
| Message-ID | <jpma7b$bsr$1@dont-email.me> |
| In reply to | #1112 |
Schmidt has brought this to us :
> Am 23.05.2012 18:14, schrieb Tom Shelton:
>> Mike Williams explained on 5/23/2012 :
>>> "Tom Shelton" <tom_shelton@comcast.invalid> wrote in message
>>> news:jpgh91$7at$1@dont-email.me...
>>>
>>>> If you plan on having a future programming in a windows
>>>> environment, I would ignore these chumps. VB6 is dead,
>>>> dead, dead.
>>>
>>> . . . and so is Windows as far as the consumers who spend most of
>>> the
>>> money are concerned. If you're planning on having a future in
>>> programming then move away from Windows, period!
>>
>> LOL... I don't fully disagree with this response actually :)
>>
>
> Well, then why this recommendation to use ".NET instead"
> (which is definitely not that beginner-friendly as VB.Classic)?
I will agree it is not quite as "beginner-friendly" - but, VB.CLASSIC
is not going to teach you much that you need to know if you expect to
have longterm skills doing windows programming.
> When we "all agree" that Windows has no future (in the
> context of "classically compiled Desktop-apps)
Who said that? C++ is still available if you are somehow anti-JIT.
And, if you noticed, I didn't say I completely aggreed with Mike.
> - then I think,
> that it is highly probable, that VB.Classic-compiled Binaries
> will perhaps have an equal timespan compared with .NET-Assemblies,
> as long as we talk about Operating-Systems, which will support
> such "real, full-featured Desktop-Apps".
>
I'm not sure how you come to that conclusion... First of all, yes -
there might be certains code tweeks you would need ot make to run under
a metro environment - since under winrt, some parts of the full
framework are not available. But, unlike VB6 binaries - they can be
made to work in that environment.
> So, as I see it, the OP has to decide (or ask the customer
> again), if the planned App in question shall be working on
> current Desktop-Machines (from XP, over Vista/Win7 up to Win8) -
> and the timespan which covers those machines and their usual
> "Office-environment-OS" from current reality (XP) up to
> Win8 Desktop-Installations is more than 5 years from now.
>
> If Tablet-Usage is *not* planned for this Application -
> and if there's *no* hint currently, that the App in question
> needs to "go online" or needs to be "run in a Browser",
> then implementing such a "pure Desktop-App" in VB.Classic
> would be the least trouble for somebody like the OP (IMO).
>
Nope. What was requested is very easy in .net. the op, just needs to
cross the biggest hurdle that .net has - learnign the class library.
> It would be in no way "less future-proof", compared with
> a .NET-2.0 App (your recommendation) which is using WinForms.
>
Not directly. But you are missing the bigger point. This app, well
it's childs play in either .net or vb.classic. But, which is better to
learn now? The one that will open up the
> So why exactly should the OP not use VB-Classic for such
> a Desktop-Application?
>
> - "Fully OOP" is questionable for a beginner, who will
> perhaps not even use Classes or the Implements-Keyword
> in VB6... and the inheritance concept *is* by no means
> something like a "holy grail".
>
You don't have to use OOP to anymore extent than you would in
VB.Classic. The point is - it's there if you want it.
> - Threading is questionable as well, having a beginner in mind
> (although VB6 supports that quite well, as you know).
>
You've got to be kidding me! Threading supported well in VB.CLASSIC?
Absolutely not. Yes, threading can be done - but, to call it well
supported is a joke.
And, yes - threading is questionable for a beginner - but, beginners
can ultimately become more than that. So, why limit yourself to a
progarmming langauge that 1) Absolutely does not support threading well
and 2) has absolutley no future.
> - same thing for your "extensive and easy to use built in
> class library..." These deep nested class-hierarchies are:
> Not.Exactly.Beginner.Friendly(In->My.Opinion)
You've got to be kiddng me.. Seriously. I'm not going to get in that
argument.
> (checking in a COM-Dll or an OCX with a simple MouseClick
> in the VB6-IDE can do the job as well as far as libs are
> concerned, and in VB6 the developer can decide himself about
> the "amount of dependencies" the App gets distributed with)
What? outside of the framework it's self - you have the same control
in .net. Obiously, you need the framework installed - and it is on any
machine running vista or above....
> - same thing for throwing linq at a beginner, who's
> perhaps not even "fluent" in "applying simple SQL"
> (against a classic and simple Desktop-DB) for his
> "set-based sort- and filter-operations".
You do understand that was a feature list right? Things that make it
supperior. No, a beginner is not going to use them... See threading.
Beginners become experts (well, if they want).
See, that's your problem - you are so backwards thinking.
> - same thing for "lambda-support"
> (would be nice BTW, if you could give a useful example,
> I'm pretty sure, a (functionally) equivalent result in VB6
> will not consume much more lines of code, and the resulting
> VB6-Code will be easier to understand as well...
>
Simple example - from the msdn documentation:
Dim increment1 = Function(x) x + 1
Dim increment2 = Function(x)
Return x + 2
End Function
' Write the value 2.
Console.WriteLine(increment1(1))
' Write the value 4.
Console.WriteLine(increment2(2))
Usefulness - very. You can pass functions as variables to other
methods. You can return them from functions. You can capture local
variables... I doubt you can truely replicate a lambda in VB6 - at
least in a non-trivial amount of code:
Sub Main()
Dim l As New List(Of Integer) From {1, 2, 3, 4, 5}
Dim x = 3
Console.WriteLine(l.Find(Function(i) i = x)) ' writes 3
End Sub
> So what it boils down to, is the original question of
> the OP, who wants to put a simple GUI-App together
> (applying filters to a list, which in turn hands
> out the correct "Video-Path" which then gets set as
> the File-input to a simply "plugged in" WMP-Control)...
> not exactly rocket-science if you ask me - and since
> it is planned, to already make use of the WMP-Control,
> then VB6 is the perfect "glueing-language" for such
> COMponents.
>
Why, you can play movies in .net quite easily. You just add the
compontrol to your toolbox, and then drop it on the form.. You know,
the sameeone you use in VB6?
But, ultimately my suggesetion isn't about this particular project -
it's about learning an environment that will be more useful going
forward...
> Also with regards to "lines of code" and "easy deployment",
> paired with an uncomplicated, fast and comparatively small
> (unbloated) IDE, VB6 is IMO the best choice for a beginner
> with some (Quick-)Basic background.
>
I disagree.
Lines of code - most things are going to be the same in VB6 vs VB.NET.
And ease of install, well, it's mostly xcopy - provided the framework
is installed. And, as noted - the .NET2.0 framework will probably be
on most computers..
> Also his:
> "I'm writing this software for deloyment on workstations
> that are connected to a pretty tightly controlled Gov network"
> reads like that this is indeed planned as a "normal Desktop-
> App" ... perhaps rolled out to the greater part to XP-
> installations (on the workstations in question), which
> definitely come with a preinstalled VB6-runtime (.NET 2.0
> is by no means "a given" on XP) - and also very likely with
> a preinstalled Windows-Media-Player-COM-lib (the thingy,
> named wmp.dll in \System32\ or \SysWOW64\ in Win7-64).
My guess, is that yes at least .net 2.0 is. I have done contract work
for the US Airforce. And, guess what - they use a lot of .net stuff.
> IMO he didn't ask "I'm planning a long-term programming-
> career, what language or platform is the most recommendable
> in terms of "available jobs" or its "future-proofness".
I don't care if he asked that or not. The OP may or not know
themselves if they want taht - but, advising him to learn an out dated
language, isn't going to help them if they ultimately decide that's
what he wants to do.
> If that would have been asked, then my answer would be:
> C++ paired with wxWidgets or QT
> Java
>
I guess that really depends on your ultimate programming and how you
feel about the future of windows programming. If you think you are
going to be on windows - well, wxWidgets, QT, and Java are frankly just
as dead as VB (unless they create metro versions :) )
I have no problem with the C++ suggestion... Though, it seems a little
strange - considering your thoughts on using vb.net vs vb6 for a
beginner.
> ... and nowadays barely a mistake: ...
>
> HTML5/JS + jQuery at the client- (browser-)side, paired
> with one of the many (Web-)server-side platforms/languages
> (as Rails or PHP or Web2Py or Java or Node.js).
>
> But IMO he asked about a tool, able to "get the job
> done", in a reasonable (more or less short) time, and
> as long as there's a "classically compiled Desktop-App"
> the customer wants, then VB6 is a reasonable, "least
> efforts" choice.
It was explicitly asked how to do it in VB.NET. You chumps swooped in
with your anti-.net diatribe and convinced him that it would somehow be
better to use the hopelessly antiquated (don't get me wrong, vb6 was
good in it's day - but, that day has LONG passed) language.
And here is the answer...
Public Class Form1
Private Class MovieInfo
Public Sub New(ByVal path As String)
FullPath = path
End Sub
Public Property FullPath As String
Public ReadOnly Property DisplayName As String
Get
Return Path.GetFileNameWithoutExtension(FullPath)
End Get
End Property
End Class
Private Sub Form1_Load(sender As System.Object, e As
System.EventArgs) Handles MyBase.Load
uxMovies.DisplayMember = "DisplayName"
For Each filePath In Directory.EnumerateFiles(MoviePath,
"*.wmv") ' you would have to change this line a bit for .net 2.0
uxMovies.Items.Add(New MovieInfo(filePath))
Next
End Sub
Private Sub uxMovies_DoubleClick(sender As System.Object, e As
System.EventArgs) Handles uxMovies.DoubleClick
If Not IsNothing(uxMovies.SelectedItem) Then
uxPlayer.URL = (DirectCast(uxMovies.SelectedItem,
MovieInfo)).FullPath
uxPlayer.Ctlcontrols.play()
End If
End Sub
Private ReadOnly Property MoviePath As String
Get
Return ConfigurationManager.AppSettings("moviePath")
End Get
End Property
End Class
Gee... taht was rough, 10 minutes or so...
--
Tom Shelton
[toc] | [prev] | [next] | [standalone]
| From | "Mike Williams" <Mike@WhiskyAndCoke.com> |
|---|---|
| Date | 2012-05-25 06:52 +0100 |
| Message-ID | <jpn6lo$lsu$1@dont-email.me> |
| In reply to | #1113 |
"Tom Shelton" <tom_shelton@comcast.invalid> wrote in message news:jpma7b$bsr$1@dont-email.me... >> Schmidt has brought this to us : >> Well, then why this recommendation to use ".NET >> instead" (which is definitely not that beginner-friendly >> as VB.Classic)? > > I will agree it is not quite as "beginner-friendly" - but, > VB.CLASSIC is not going to teach you much that > you need to know if you expect to have longterm > skills doing windows programming. Neither is VB.Net. Nothing at all about Windows programming is going to be long term! The King is dying . . . and the vultures are circling. Mike
[toc] | [prev] | [next] | [standalone]
| From | Schmidt <sss@online.de> |
|---|---|
| Date | 2012-05-25 11:14 +0200 |
| Message-ID | <jpnihd$v7t$1@speranza.aioe.org> |
| In reply to | #1113 |
Am 24.05.2012 23:46, schrieb Tom Shelton:
>> When we "all agree" that Windows has no future (in the
>> context of "classically compiled Desktop-apps)
>
> Who said that?
Mike said that, and I'm also of the opinion (same as Maya
and a whole lot of others, not all Members of the VB-community),
that Windows is on its way to a "closed OS".
Closed in a sense, that the OS-Vendor dictates the choice
of programming-tools and environments, as well as your
deployment-target (App-stores).
And the final environment for an "App-Developer" will
be HTML5/JS as it seems currently, paired with the
appropriate accompanying tools at the (Web-)serverside.
So in this "world" neither a .NET 2.0 Winforms-App will
run, nor a VB6-App. And both kind of Application-Binaries
stop working at the same time - so why "learn VB6" -
or why "learn .NET 2.0 WinForms"?
Because it works here and now - and also for at least the
next 5 years (on the classical "company-desktop-PC").
And since XP is with high probability a deployment-target
for the OP, then VB6 is the better choice for this kind
of (relative simple) task, since no bloated runtime needs
to be deployed with his simple Media-Player-App.
> C++ is still available if you are somehow anti-JIT.
I'm not "anti-JIT" - I'm "anti-BullShit".
And your continued .NET marketing-drivel in this group
is exactly that.
Your recommendation to learn .NET is misleading
because it is not the easiest way to achieve the
goal of the OP - VB6 *is* the simpler tool for the task
(especially when XP is one of the potential deployment-targets).
> This app, well it's childs play in either
> .net or vb.classic. But, which is better to
> learn now?
Neither one, when one is inclined to think, that
"the world" seems to be moving to WebApps.
And because it's childs play as you say, then
choosing a tool which makes the least deployment-
trouble is the way to go.
If the OP is ambitious, then what he should do
after delivery of the simple VB6-App, is to use
the next year or so, to learn HTML5/JS and to
(re)write the same thing again as a Browser-App.
[Threading]
> You've got to be kidding me! Threading supported well in VB.CLASSIC?
> Absolutely not. Yes, threading can be done - but, to call it well
> supported is a joke.
It is well supported enough in VB6, in a way which allowed
to e.g. write a threaded Mandelbrot-App, which ran about
10 times as fast as what you personally delivered from
your "well supported threading-kitchen in .NET".
To the OP:
We had this threading-discussion already over and over
again - ending up in something like a "shootout" - and
Tom was finally not able to come up with a well-working
demonstration.
He is not really a programmer in my opinion - just look
at his poor examples for the lambda-functionality he
advertised. Copy and paste from MSDN.
He's advertising features which were never really
used or well understood in his daily .NET-practise
(same as threading).
> Why, you can play movies in .net quite easily.
> You just add the compontrol to your toolbox, You know,
> and then drop it on the form.. the sameeone you use in VB6?
Exactly.
And the wmp.dll is a COM-component, which is directly
addressed in VB6, so why burden the OP with the necessity
to deploy a (in this case useless) .NET 2.0 runtime,
which addresses this COM-component indirectly?
You see, VB6 as a tool has never disappointed on the
classical Win-Desktop - and it will work as long as
the classical Win-Desktop lives.
As it seems the development goes, .NET was only a
"side-branch" of overbloated tools, which were working
on top of the Win32-API and COM.
A diversion, an absolutely unnecessary indirection for
Win-Desktop-Apps.
Both, VB6-Desktop-Apps as well as .NET-Desktop-Apps
will go "out of scope" at the same time...
So why again should VB6-developers should have switched
to .NET in the first place?
A waste of time that would have been - and I'm sure you
come across that "pissed off" in your latest responses,
because you realize that now - you wasted your time with
learning .NET.
The future tools (for me) lay elsewhere.
You may color me "backwards", but I've invested my time
over the last years into learning different (platform-
independent) libraries, into learning C/C++, JS jQuery
and HTML5.
IMO a better time-investment than you did, Tom.
> If you think you are going to be on windows - well,
> wxWidgets, QT, and Java are frankly just as dead as
> VB (unless they create metro versions :) )
You advertised (misleadingly) .NET over the last 10 years
(as the best invention since sliced bread) ... now you
suddenly switch over to Metro as the next best "fashionable
thingy".
What if Win8 will be the next Vista...?
What if Metro as the next (now COM-based) class-library
will be the next (.NET-like) flop, because it perhaps
will not carry through for rich Desktop-Applications,
in case the companies out there want exactly that?
I'd be really careful with this last move of MS
(with regards to investing my time) ... same thing
as I did with .NET...
And as for your posted Code-snippet - here's the VB6-Version:
'***Into a VB-Form which hosts a ListBox and a MediaPlayer-Control
'-------------------------------------------------
Const MoviePath = "C:\Windows\Performance\WinSAT\"
Private Sub Form_Load()
Dim FName As String
FName = Dir(MoviePath & "*.wmv")
Do While Len(FName)
lstMovies.AddItem Left(FName, InStrRev(FName, ".wmv", , 1) - 1)
FName = Dir
Loop
End Sub
Private Sub lstMovies_Click()
WMP.URL = MoviePath & lstMovies.Text & ".wmv"
End Sub
'------------------------------------------------
To the OP:
The above is doing the same thing as the code Tom has
posted, now compare yourself.
Furthermore, if you compile that thing with VB6,
you will get an XCopy-deployable, small Executable,
which will run on all versions of Windows
(from XP to Win7) as long as the Windows Mediaplayer
is installed (which is usually the case, you will have
to check that though on your target-environment).
Olaf
[toc] | [prev] | [next] | [standalone]
| From | "DaveO" <djo@dial.pipex.com> |
|---|---|
| Date | 2012-05-25 10:57 +0100 |
| Message-ID | <jpnl1k$ulj$1@dont-email.me> |
| In reply to | #1116 |
"Schmidt" <sss@online.de> wrote in message news:jpnihd$v7t$1@speranza.aioe.org... > And as for your posted Code-snippet - here's the VB6-Version: > > '***Into a VB-Form which hosts a ListBox and a MediaPlayer-Control > '------------------------------------------------- > Const MoviePath = "C:\Windows\Performance\WinSAT\" > > Private Sub Form_Load() > Dim FName As String > FName = Dir(MoviePath & "*.wmv") > Do While Len(FName) > lstMovies.AddItem Left(FName, InStrRev(FName, ".wmv", , 1) - 1) > FName = Dir > Loop > End Sub > > Private Sub lstMovies_Click() > WMP.URL = MoviePath & lstMovies.Text & ".wmv" > End Sub > '------------------------------------------------ Tsk, that's a bit over complicated, junk all the crap in the Load event and replace the Listbox with a FileListBox. Although admittedly that'll show the extensions that your code omits. Yeah I know the FileListBox is rather ugly but if you want it simple........ Incidentally is Left(FName, InStrRev(FName, ".wmv", , 1) - 1) Quicker or better than: Left$(FName, Len(FName) - 4) Which given a 3 character extension should give the same result? DaveO.
[toc] | [prev] | [next] | [standalone]
| From | Schmidt <sss@online.de> |
|---|---|
| Date | 2012-05-25 13:36 +0200 |
| Message-ID | <jpnqrb$kh0$1@speranza.aioe.org> |
| In reply to | #1117 |
Am 25.05.2012 11:57, schrieb DaveO:
> Yeah I know the FileListBox is rather ugly but
> if you want it simple........
Just wanted to come up with the roughly identical
functionality of Toms example.
> Incidentally is
> Left(FName, InStrRev(FName, ".wmv", , 1) - 1)
> Quicker or better than:
> Left$(FName, Len(FName) - 4)
> Which given a 3 character extension should give the same result?
Good catch, what I had in mind was not:
Left(FName, InStrRev(FName, ".wmv", , 1) - 1)
but perhaps
Left(FName, InStrRev(FName, ".") - 1)
which I normally use here, to get rid of a file-
extension of variable length in a generic way,
but from the top of my head failed to hack-in
correctly for this specific example.
Olaf
[toc] | [prev] | [next] | [standalone]
| From | "Mayayana" <mayayana@invalid.nospam> |
|---|---|
| Date | 2012-05-25 09:25 -0400 |
| Message-ID | <jpo0sl$296$1@dont-email.me> |
| In reply to | #1116 |
| And the final environment for an "App-Developer" will
| be HTML5/JS as it seems currently, paired with the
| appropriate accompanying tools at the (Web-)serverside.
|
There's an interesting link here, related to that:
http://msdn.microsoft.com/en-us/library/windows/apps/br211369.aspx
Only C++ will have access to the "Win32 and COM API"
in Win8 x86 Metro, and of course, nobody gets it on WinARM.
.Net on x86 Metro gets WinRT and part of the .Net framework.
It's getting squeezed out in terms of relevance. I don't
know exactly what .Net can or can't do in Metro as compared
to javascript, but it doesn't look like there's much difference.
It's rather ironic. The cloud craze is what MS has been
trying to do with .Net for over 10 years now: To get
3rd-party programmers into a sandbox, preferably also
finding a way to take a cut of their earnings. Now MS is
closer to that goal than ever, but the pendulum has swung
so far that even .Net is too functional, being replaced by
"DHTML on steroids".
The one thing I wonder about in all this is business, hobby,
government and professional use of actual computers. A tablet
or crippled PC might be fine for Facebook, shopping and email,
but wasn't that also the selling point of the ill-fated WebTV
and "thin clients"? Restricting the end-user was fine for Apple.
Their PCs are already somewhat restricted and now they have
a booming business in fully restricted tablets and phones. But
with Microsoft, to succeed in their plan implies that such things
as Photoshop, Autocad, scientific software, etc. will
have to run either as webpage-only or move to Linux. It's hard
to see that happening, not only because of the sheer inefficiency
of converting such things to web-apps for no good (technical)
reason, but also because of the privacy/security issues.
I know it's not fashionable to question the retail cloud model
these days, but to me it still looks like mostly a business plan in
search of a purpose; the best idea that big tech companies
could come up with, now that most people don't need to buy
new PCs or software very often. The potential for profit with the
cloud model is clear. But the benefit for the customer, aside from
casual use of things like gmail, is not clear.
[toc] | [prev] | [next] | [standalone]
| From | Tom Shelton <tom_shelton@comcast.invalid> |
|---|---|
| Date | 2012-05-25 10:12 -0600 |
| Message-ID | <jpob1a$434$1@dont-email.me> |
| In reply to | #1116 |
Schmidt presented the following explanation :
> Am 24.05.2012 23:46, schrieb Tom Shelton:
>
>>> When we "all agree" that Windows has no future (in the
>>> context of "classically compiled Desktop-apps)
>>
>> Who said that?
> Mike said that, and I'm also of the opinion (same as Maya
> and a whole lot of others, not all Members of the VB-community),
> that Windows is on its way to a "closed OS".
> Closed in a sense, that the OS-Vendor dictates the choice
> of programming-tools and environments, as well as your
> deployment-target (App-stores).
>
> And the final environment for an "App-Developer" will
> be HTML5/JS as it seems currently, paired with the
> appropriate accompanying tools at the (Web-)serverside.
>
? If you are going to do web development, taht would seem appropriate.
And it can be used in the future to develop some windows apps - but
that is only one option.
> So in this "world" neither a .NET 2.0 Winforms-App will
> run, nor a VB6-App. And both kind of Application-Binaries
> stop working at the same time - so why "learn VB6" -
> or why "learn .NET 2.0 WinForms"?
>
What are you babeling about? I've never talked about webstuff. And,
yes if ms kills the legacy desktop - then a "windows forms" app will
stop working.
But, as usuall you miss the point. It's about choices and options.
And, leanring VB6 leaves you none. Excpet to be stuck in the legacy
desktop, 32-bit world.
> Because it works here and now - and also for at least the
> next 5 years (on the classical "company-desktop-PC").
>
> And since XP is with high probability a deployment-target
> for the OP, then VB6 is the better choice for this kind
> of (relative simple) task, since no bloated runtime needs
> to be deployed with his simple Media-Player-App.
>
>
LOL... You guys and that whole bloated thing are really getting
tiresome. Seriously. The disk footprint is so small on any machine
made in the last 10 years that it isn't a consideration. The memory
footprint, while higher than VB.CLASSIC - is not a significant factor.
>> C++ is still available if you are somehow anti-JIT.
> I'm not "anti-JIT" - I'm "anti-BullShit".
>
> And your continued .NET marketing-drivel in this group
> is exactly that.
>>
> Your recommendation to learn .NET is misleading
> because it is not the easiest way to achieve the
> goal of the OP - VB6 *is* the simpler tool for the task
> (especially when XP is one of the potential deployment-targets).
>
My recomendation was actually not to use any VB. But, learning vb.net
is clearly going to be better alternative to a language whose toolset
is unsupported and dead in the market. And considering that the OP was
already using VB.NET...
And, my guess would be - given I have done contract work for the
government - that those machines all already have .net 2.0, as do most
other xp machines. So, targeting .net 2.0 in this environment is
almost certainly an xcopy install. I specified 2.0 simply because it
has the largest installed base. I obviously can't make a guarentee all
of those machines do - because I'm sure that different branches of the
gov might have different polocies - but it's something easily checked.
I work for a very large company, and I know every single one of the
10's of thousands of machines here have at least .net 3.5 installed.
These environments tend to be managed.
>
>> This app, well it's childs play in either
>> .net or vb.classic. But, which is better to
>> learn now?
>
> Neither one, when one is inclined to think, that
> "the world" seems to be moving to WebApps.
>
I dont' think that is the case actually. Lot's of evidence shows that
users of mobile devices will prefere a native app over a web
experience. So, while the web is important - it's not everything.
And even if it were the case, learning .net would still be just as
valuable.
> And because it's childs play as you say, then
> choosing a tool which makes the least deployment-
> trouble is the way to go.
>
I can almost certainly guarntee you that the OP will have not have a
difficult time distributine thier app. .NET 4 - probably, especially
since in a lot of managed environmnets, users don't have admin rights
and the 4.0 runtime is not a common thing to find preinstalled. Which
is why I suggested targeting 2.0 - which I can tell you with 95-100%
certainty is already on those machines.
> If the OP is ambitious, then what he should do
> after delivery of the simple VB6-App, is to use
> the next year or so, to learn HTML5/JS and to
> (re)write the same thing again as a Browser-App.
>
A year to learn html5/js? You must mean in depth expertise - because I
would think you should be able to learn the basics in a few weeks at
most. Especially to recreate this app.
I'm not disagreeing with you in the main. It is a valuable skill - I
always advocate expanding horizons.
>
> [Threading]
>> You've got to be kidding me! Threading supported well in
>> VB.CLASSIC?
>> Absolutely not. Yes, threading can be done - but, to call it well
>> supported is a joke.
>
> It is well supported enough in VB6, in a way which allowed
> to e.g. write a threaded Mandelbrot-App, which ran about
> 10 times as fast as what you personally delivered from
> your "well supported threading-kitchen in .NET".
>
> To the OP:
> We had this threading-discussion already over and over
> again - ending up in something like a "shootout" - and
> Tom was finally not able to come up with a well-working
> demonstration.
>
That thread was not about speed - you made it so after the fact. It
was about comparing threading models. I was very clear up front that I
did not believe I could make it as fast as the vb6 version. Simply
because I am not an expert when it comes to graphic manipulation - it's
just not what I do. In fact, I don't write many interfaces at all.
Further, I'm pretty sure I pointed out that winforms are slower for
those sorts of operations in general - they rely on gdi+ rather than
gdi.
> He is not really a programmer in my opinion - just look
> at his poor examples for the lambda-functionality he
> advertised. Copy and paste from MSDN.
>
Yes. Because I had to look up the exact syntax in vb. I'm not a vb
programmer, so I sometimes forget VB's quirks. I thought it was a very
concise example - not only concise - but, one you would have a hard
time replicating in vb6.
And that was only the first part. The list searching - that was mine.
> He's advertising features which were never really
> used or well understood in his daily .NET-practise
> (same as threading).
>
I uses lambda's in C# on almost a daily basis. Many of the times, the
actual use is trivial - searching a lsit, iterating a list, linq
statements, etc - but they often lead to more concise code, so I tend
to favor their use:
foreach (var x in myList)
Console.WriteLine(x);
vs
myList.ForEach (x => Console.WriteLine);
Matter of taste, I guess.
But, they are usefull for all kinds of things - they are essentially a
typesafe function pointer... Like I said earlier, they can be passed as
an argument to a function where you might want the caller to provide
some functionality. One specfic place I have made use of them, are
situations where a function may operate differently based on a "mode"
parameter. Here is a really simple example (and, I wrote this):
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
namespace ConsoleApplication22
{
class Program
{
static void Main ( string[] args )
{
Console.WriteLine ( SimpleCalc.Calculate ( 1, 1, MathOp.Add
) );
Console.WriteLine ( SimpleCalc.Calculate ( 10, 5,
MathOp.Subtract ) );
Console.WriteLine ( SimpleCalc.Calculate ( 5, 5,
MathOp.Multiply ) );
Console.WriteLine ( SimpleCalc.Calculate ( 20, 10,
MathOp.Divide ) );
}
}
enum MathOp
{
Add,
Subtract,
Multiply,
Divide
}
static class SimpleCalc
{
private static Dictionary<MathOp, Func<int, int, int>> MathOps;
static SimpleCalc ()
{
MathOps = new Dictionary<MathOp, Func<int, int, int>> ()
{
{MathOp.Add, ( x, y ) => Add( x, y )},
{MathOp.Subtract, ( x, y ) => Subtract( x, y )},
{MathOp.Multiply, ( x, y ) => Multiply( x, y )},
{MathOp.Divide, ( x, y ) => Divide( x, y )}
};
}
public static int Calculate ( int x, int y, MathOp op )
{
return MathOps[op] ( x, y );
}
private static int Add ( int x, int y )
{
return x + y;
}
private static int Subtract ( int x, int y )
{
return x - y;
}
private static int Multiply ( int x, int y )
{
return x * y;
}
private static int Divide ( int x, int y )
{
return x / y;
}
}
}
Yes, I could accomplish the same thing in a more concise manor using a
swith statement or a if/else if/else structure - but, I find this style
enhances long term maintainabilty. Adding additional "modes" becomes
trivial. For more complex variations, I lean to using more of a
command pattern design...
>
>> Why, you can play movies in .net quite easily.
>> You just add the compontrol to your toolbox, You know,
>> and then drop it on the form.. the sameeone you use in VB6?
>
> Exactly.
> And the wmp.dll is a COM-component, which is directly
> addressed in VB6, so why burden the OP with the necessity
> to deploy a (in this case useless) .NET 2.0 runtime,
You are assuming that the runtime is not already there - and I again
can almost guarntee it is. Not to the degree that I can with vb6 -
because the runtime didn't ship by default with xp. It's possible that
this branch of government doesn't use any .net apps - and that the .net
runtime is not part of it's standard image... But VERY unlikely.
> which addresses this COM-component indirectly?
>
I in fact, usually avoid using COM components in .NET - because, yes
there is a performance penalty for using them - and they can often
complicate your deployment. And that goes for VB6 as well - third
party controls for example will often complicate a deployment. But, in
this case - the hit is not going to make any noticable difference since
it's not a "chatty" interface.
> You see, VB6 as a tool has never disappointed on the
> classical Win-Desktop - and it will work as long as
> the classical Win-Desktop lives.
Only there, and only as long as they support Win32.
> As it seems the development goes, .NET was only a
> "side-branch" of overbloated tools, which were working
> on top of the Win32-API and COM.
>
> A diversion, an absolutely unnecessary indirection for
> Win-Desktop-Apps.
>
> Both, VB6-Desktop-Apps as well as .NET-Desktop-Apps
> will go "out of scope" at the same time...
>
Yes, but all of the skills will be tranferable. And much of the code
as well (especially if it is well structured) - assuming we're still
talking about talking about windows...
If windows dies, than we will all have to change. No biggie to me - I
can make the jump to java or c++ pretty easily if needed.
> So why again should VB6-developers should have switched
> to .NET in the first place?
>
> A waste of time that would have been - and I'm sure you
> come across that "pissed off" in your latest responses,
> because you realize that now - you wasted your time with
> learning .NET.
LOL. You are completly wrong. I have absolutely no regrets at all.
I've gotten to do a lot of cool stuff. Write cool code and make a far
better living than I ever did doing VB.CLASSIC. I like change - and I
know I would be bored out of my skull if I'd stuck to VB.CLASSIC. The
eternally unchanging.
> The future tools (for me) lay elsewhere.
>
Cool.
> You may color me "backwards", but I've invested my time
> over the last years into learning different (platform-
> independent) libraries, into learning C/C++, JS jQuery
> and HTML5.
>
> IMO a better time-investment than you did, Tom.
>
That's your opinion. And your welcome to it. But, I already have
knowledge in C/C++ and I have html and javascript experience (as well
as java, perl, and even php). I worked in a mixed windows/*nix shop
for over 8 years. In other words, even if .NET dissappeard today - I
would still be ok... I do what I do because I love it - not because I
have to.
>> If you think you are going to be on windows - well,
>> wxWidgets, QT, and Java are frankly just as dead as
>> VB (unless they create metro versions :) )
>
> You advertised (misleadingly) .NET over the last 10 years
> (as the best invention since sliced bread) ... now you
> suddenly switch over to Metro as the next best "fashionable
> thingy".
>
LOL... No, it's called seeing the writing on the wall. I'm actually,
that thrilled about metro on the desktop. But, I do like the
underlying technology. If you had ever done anythign with wpf, you
might agree.
> What if Win8 will be the next Vista...?
What if? And, as you see I did not tell the op to target metro. I
simply was pointing out that, if they should so desire - that would be
an option for them. Not so with vb6.
> What if Metro as the next (now COM-based) class-library
metro is not com based - winrt is. And it makes sense. Even .net uses
com.
> will be the next (.NET-like) flop, because it perhaps
> will not carry through for rich Desktop-Applications,
> in case the companies out there want exactly that?
>
Calling .net a flop is rich. LOL. I've had more employment and offers
of employment doing .net than I ever did with vb6. .NET is very
heavily used in the same places VB6 was - custom business apps. VB6
was never a very good choice for mass market software. Still isn't.
> I'd be really careful with this last move of MS
> (with regards to investing my time) ... same thing
> as I did with .NET...
>
>
> And as for your posted Code-snippet - here's the VB6-Version:
>
> '***Into a VB-Form which hosts a ListBox and a MediaPlayer-Control
> '-------------------------------------------------
> Const MoviePath = "C:\Windows\Performance\WinSAT\"
>
> Private Sub Form_Load()
> Dim FName As String
> FName = Dir(MoviePath & "*.wmv")
> Do While Len(FName)
> lstMovies.AddItem Left(FName, InStrRev(FName, ".wmv", , 1) - 1)
> FName = Dir
> Loop
> End Sub
>
> Private Sub lstMovies_Click()
> WMP.URL = MoviePath & lstMovies.Text & ".wmv"
> End Sub
> '------------------------------------------------
>
You reallize, that that almost that exact code (I say almost because
when I do write vb code, I always do it with option strict on - and
your code well, fails to compile when you have strict type checking
enabled) works in vb.net as well? I did it the way I did, because I
prefere to use the framework when dealing with paths. That probably
comes from the fact, I've done coding on linux using C#/Mono. So, it
keeps things more portable. Also, I'm not a VB programmer anymore - so
I don't think in terms of VB runtime functions :)
> To the OP:
>
> The above is doing the same thing as the code Tom has
> posted, now compare yourself.
>
Public Class Form1
Const MoviePath As String = "c:\users\tom\videos\"
Private Sub Form1_Load(sender As System.Object, e As
System.EventArgs) Handles MyBase.Load
Dim FName As String
FName = Dir(MoviePath & "*.wmv")
Do While Len(FName) > 0
uxMovies.Items.Add(Strings.Left(FName, InStrRev(FName,
".wmv", , CompareMethod.Text) - 1))
FName = Dir()
Loop
End Sub
Private Sub uxMovies_DoubleClick(sender As System.Object, e As
System.EventArgs) Handles uxMovies.DoubleClick
If Not IsNothing(uxMovies.SelectedItem) Then
uxPlayer.URL = MoviePath & uxMovies.SelectedItem.ToString()
& ".wmv" '(DirectCast(uxMovies.SelectedItem, MovieInfo)).FullPath
End If
End Sub
End Class
There you go - your nasty code made working in .net. Only a couple
tweaks to allow for option strict.
> Furthermore, if you compile that thing with VB6,
> you will get an XCopy-deployable, small Executable,
> which will run on all versions of Windows
Granted, with the .net compile you don't get a single exe. You get an
exe and a couple dll's to handle the com interop totalling a bit more
than 400 KB. They will be xcopy deployable to all windows machines
vista and higher. If this was being deployed to the "world" in
general, than a small percentage of xp machines would need to have the
framework installed - but, given the environmen the op indicated in his
orignal post, that isn't likely to be the case. But if it is the
case... I still would not suggest VB.CLASSIC. Even powerbasic would
be a better option - at least it still is a living supported dev
environment.
--
Tom Shelton
[toc] | [prev] | [next] | [standalone]
| From | "Mayayana" <mayayana@invalid.nospam> |
|---|---|
| Date | 2012-05-25 12:27 -0400 |
| Message-ID | <jpobr8$93n$1@dont-email.me> |
| In reply to | #1122 |
| I work for a very large company, and I know every single one of the | 10's of thousands of machines here have at least .net 3.5 installed. | These environments tend to be managed. The OP already said that he was installing to machines that didn't have the necessary .Net framework. That's really not a small issue. The XP newsgroup is filled with posts from people who had bad luck with a bad .Net update, and then couldn't uninstall to start over again.
[toc] | [prev] | [next] | [standalone]
| From | Tom Shelton <tom_shelton@comcast.invalid> |
|---|---|
| Date | 2012-05-25 14:22 -0600 |
| Message-ID | <jpoplp$41a$1@dont-email.me> |
| In reply to | #1123 |
Mayayana wrote : >> I work for a very large company, and I know every single one of the >> 10's of thousands of machines here have at least .net 3.5 installed. >> These environments tend to be managed. > > The OP already said that he was installing to machines > that didn't have the necessary .Net framework. That's > really not a small issue. The XP newsgroup is filled with > posts from people who had bad luck with a bad .Net > update, and then couldn't uninstall to start over again. Go look - he was targeting 4.0. That's why I suggested 2.0.... It will almost certainly be there (actualy, 3.5 will probably be there as well, but, 2.0 is a safer bet). And he can always check on the default image -- Tom Shelton
[toc] | [prev] | [next] | [standalone]
| From | Schmidt <sss@online.de> |
|---|---|
| Date | 2012-05-26 18:38 +0200 |
| Message-ID | <jpr0uo$1uj$1@speranza.aioe.org> |
| In reply to | #1122 |
Am 25.05.2012 18:12, schrieb Tom Shelton:
> And, yes if ms kills the legacy desktop -
> then a "windows forms" app will stop working.
>
> But, as usuall you miss the point.
Ok, let's see who's missing the point.
> It's about choices and options. And, leanring VB6 leaves you none.
> Excpet to be stuck in the legacy desktop, 32-bit world.
So, if MS *is* killing the classic-desktop over the next years,
then you would have to rewrite your VB6-App... In the same
way, as you would have to rewrite your .NET 2.0 Winforms-App
(not much in a Winforms-App that "maps" directly to
Metro-WPF/WinRT or HTML5/JS, is there?).
So, why start with .NET 2.0 (your recommendation) at all,
when the VB6-Coding is easier done, and has less deployment-
problems?
> My recomendation was actually not to use any VB.
But you do realize, that this group is a VB-group?
> But, learning vb.net is clearly going to be better alternative
> to a language whose toolset is unsupported and dead in the market.
As long as "the market" (the markets platform) is the Windows-
Desktop, then VB6 "is still in it" - very much alive and
kickin, as long as this markets platform (Win32-API and COM)
is a given (and this will be the case until MS pulls the plug,
and starts with the same restrictions also on x86-Hardware,
as we see it done currently - only for the ARM-target).
And as for "dead in the market" (if you really want to go there),
.NET 2.0 + Winforms already *is* dead - an early .NET-adopter
*will* have to rewrite his deprecated .NET 2.0 GUI-Applications
for the entirely different animal WPF.
So, MS has "done it again" - Code-Investments destroyed -
now one is "encouraged" (and you yourself among the
marketeers) to "rewrite stuff again", to fit the shiny
new WinRT/WPF-paradigm.
And how long will *that* last might I ask... when there's
already an alternative way offered by MS themself
("written in huge letters on the wall", so to say) -> HTML5/JS...
So, .NET 2.0 + Winforms is dead - Code-Investments (you
strongly encouraged us to do over the last years) are
blown to pieces in this special .NET-camp, dejavu again...
So, if you ask me, I see the same thing happen in a few
years, with code-investments nowadays done into .NET/WPF
(when MS will switch entirely over to the new upcoming
star HTML5/JS).
But yes, VB6-users will have to switch too at some point in
time (over the next 5 years) - but they can take a good
look in the next 2 years, where the MS-journey takes the
"adventurous" (as yourself). VB.classic-users will perhaps
port those of their Applications which worth it, to HTML5/JS
directly, using the better and better becoming tools which will
evolve around that *platformindependent* paradigm - and they
will finally have ported only *once* - whereas the ".NET shops"
(if those follow along your path of thinking), will have ported
their VB6-Apps 2 times more:
1. from VB6 to .NET Winforms
2. from .NET Winforms to .NET WPF(+WinRT)
3. from .NET WPF/WinRT to HTML5/JS finally
I hope you get it now, even when you have a slight disadvantage
in understanding (because you're not self-employed, you just
receive your monthly paychecks) - so you perhaps never had to
spend money yourself for these (IMO) wasted investments
(into development-tools and the time into not that easily
portable code-bases).
> A year to learn html5/js? You must mean in depth expertise -
Of course in depth, what else?
I see Browsers (in their latest, much faster and more capable
incarnations) as a new kind of (platform-independent) "Runtime" -
finally and nowadays working fast enough even on all kind
of different mobile-devices.
A Runtime which is not distributed in "a Dll" (or multiple Dlls),
but as a "hosting-process" (along with Dlls). A Host, which is
offering an empty "Window" (an empty "Form") - but one you can
"interact with"... the developer then responsible (as for any
"empty classic VB-Form"), to bring life into it, using Controls
or Widgets (a lot of them already built into the "Browser-Runtime",
implemented in C/C++) ... + a glue language (JS) which currently
runs already faster than VB6-PCode.
Not *all* that much different to the concept we used over the
last 15 years - it's only the loading-process of the "application-
code" and the (GUI)resources (done over sockets instead using the
FileSystem) which differs, but that one is not all that difficult
to understand and adapt to - and it has advantages too, because
you get machine-crossing RemoteProcedureCall-capabilities this
way "for free".
[usefulness of lambdas]
You gave a poor example again, since it can be
replicated in less lines of code in VB6:
'-----------------------------
Private Enum MathOp
Add
Subtract
Multiply
Divide
End Enum
Private Sub Form_Load()
Debug.Print Calculate(1, 1, MathOp.Add)
Debug.Print Calculate(10, 5, MathOp.Subtract)
Debug.Print Calculate(5, 5, MathOp.Multiply)
Debug.Print Calculate(20, 10, MathOp.Divide)
End Sub
Private Function Calculate(P1, P2, ByVal Op As MathOp)
Select Case Op
Case MathOp.Add: Calculate = P1 + P2
Case MathOp.Subtract: Calculate = P1 - P2
Case MathOp.Multiply: Calculate = P1 * P2
Case MathOp.Divide: Calculate = P1 / P2
End Select
End Function
'---------------------------------
And it is even more maintenance-friendly, since
you have to introduce a new "MathOp" only in the
Enum and with one additional line in the Select Case
construct - whereas your example would require changes
in three places.
The VB-example has (furthermore) the advantage, to
work not only with integers, but with any numeric
type - and if you want to restirct it to only one
certain allowed type, you could do so of course.
Also your .NET example needs more memory, because
you introduced a Dictionary-Instance quite unnecessarily.
There are better lambda-examples out there - but this
may serve as an example to what I said earlier -
most of your advertised .NET-features serve (for a
mid-level programmer as yourself) only as a vehicle
"to feel better" - their usage at such a skill-level
is mostly questionable and often inefficient.
[simple ListBox-triggered MediaPlayer-example]
> There you go - your nasty code made working in .net.
"Nasty" is a matter of taste - I find also your revised
example still "too wordy" for mine...
May the OP decide, <shrug>...
Olaf
[toc] | [prev] | [next] | [standalone]
| From | Tom Shelton <tom_shelton@comcast.invalid> |
|---|---|
| Date | 2012-05-26 14:12 -0600 |
| Message-ID | <jprdft$t7n$1@dont-email.me> |
| In reply to | #1128 |
Schmidt explained :
> Am 25.05.2012 18:12, schrieb Tom Shelton:
>
>> And, yes if ms kills the legacy desktop -
>> then a "windows forms" app will stop working.
>>
>> But, as usuall you miss the point.
> Ok, let's see who's missing the point.
>
>> It's about choices and options. And, leanring VB6 leaves you none.
>> Excpet to be stuck in the legacy desktop, 32-bit world.
>
> So, if MS *is* killing the classic-desktop over the next years,
> then you would have to rewrite your VB6-App... In the same
> way, as you would have to rewrite your .NET 2.0 Winforms-App
> (not much in a Winforms-App that "maps" directly to
> Metro-WPF/WinRT or HTML5/JS, is there?).
>
Most of the .net framework is availabe in a metro app. The main stuff
that changes are mostly file system access, network stuff, and of
course, p/invoke.
So, if you do a app in the correct way - you will not be rewriting the
entire app. Mainly the interface, and replacing the bit of
functionality that isn't availabe to you in metro.
> So, why start with .NET 2.0 (your recommendation) at all,
> when the VB6-Coding is easier done, and has less deployment-
> problems?
>
LOL.. How do you know there are less deployment problems? If the .net
2.0 or above framework is present - than there is no problem. It's an
xcopy deploy. And, again - the chances are that it is there.
And the coding is no harder than in vb6. It's in fact almost identical
if you turn off option strict.
>> My recomendation was actually not to use any VB.
> But you do realize, that this group is a VB-group?
>
So?
>> But, learning vb.net is clearly going to be better alternative
>> to a language whose toolset is unsupported and dead in the market.
> As long as "the market" (the markets platform) is the Windows-
> Desktop, then VB6 "is still in it" - very much alive and
> kickin, as long as this markets platform (Win32-API and COM)
> is a given (and this will be the case until MS pulls the plug,
> and starts with the same restrictions also on x86-Hardware,
> as we see it done currently - only for the ARM-target).
>
> And as for "dead in the market" (if you really want to go there),
> .NET 2.0 + Winforms already *is* dead - an early .NET-adopter
> *will* have to rewrite his deprecated .NET 2.0 GUI-Applications
> for the entirely different animal WPF.
>
Again, your missing the point. Yes, they will have to rewrite the gui
- and maybe the whole app if they were stupid about how it was
structured...
I would whole heartedly suggest taht they just write the thing using
wpf from the begining - if they could be assured of at least a .net 3.0
environment. But, the goal was:
1) to learn the language
2) learn the framework
3) minimize the possiblity of having to deploy the framework.
Personally, if I was the OP - I would just get with the IT people and
find out what is part of the standard image. And, then either do some
other platform if no .net (and that other would NOT be vb6) or target
the latest version they support. But, by just targeting 2.0 they are
pretty well assured that it will be there.
> So, MS has "done it again" - Code-Investments destroyed -
> now one is "encouraged" (and you yourself among the
> marketeers) to "rewrite stuff again", to fit the shiny
> new WinRT/WPF-paradigm.
>
I don't have to re-write hardely anything... So, not sure what your
talking about. Most of my stuff will work unchanged - other than the
UI. I don't tend to write monolithic apps.
> And how long will *that* last might I ask... when there's
> already an alternative way offered by MS themself
> ("written in huge letters on the wall", so to say) -> HTML5/JS...
>
LOL.. That is pretty limited in metro. Most serious apps are going to
be C++/C#/VB.NET + WPF.
> So, .NET 2.0 + Winforms is dead
Has been for a long time. In fact, Winforms has been in maintenance
mode since .net 3.0.
> - Code-Investments (you
> strongly encouraged us to do over the last years) are
> blown to pieces in this special .NET-camp, dejavu again...
LOL... What a load of bs. Some inteface changes - yes. But, almost
all of my code will go straight to metro. Because most of my logic is
in their own libraries... And most of the .net framework is available
in winrt.
> So, if you ask me, I see the same thing happen in a few
> years, with code-investments nowadays done into .NET/WPF
> (when MS will switch entirely over to the new upcoming
> star HTML5/JS).
>
They are not switching entirely to that. Please - stop exagerating.
There is absolutely no indication that anything of the sort will
happen.
> But yes, VB6-users will have to switch too
Who's the too? I don't have to switch to anything.
> at some point in
> time (over the next 5 years) - but they can take a good
> look in the next 2 years, where the MS-journey takes the
> "adventurous" (as yourself). VB.classic-users will perhaps
> port those of their Applications which worth it, to HTML5/JS
> directly, using the better and better becoming tools which will
> evolve around that *platformindependent* paradigm - and they
> will finally have ported only *once* - whereas the ".NET shops"
> (if those follow along your path of thinking), will have ported
> their VB6-Apps 2 times more:
> 1. from VB6 to .NET Winforms
> 2. from .NET Winforms to .NET WPF(+WinRT)
> 3. from .NET WPF/WinRT to HTML5/JS finally
>
Wow. I thought you were smarter than that. Why do you feel the need
to exagerate. .NET is still as much a part of WinRT - there are some
changes yes - but, for the most part, things will just work. The main
porting will be you gui logic - if you havent' already adopted wpf
(it's been around for a # of years already).
> I hope you get it now, even when you have a slight disadvantage
> in understanding (because you're not self-employed, you just
> receive your monthly paychecks) - so you perhaps never had to
> spend money yourself for these (IMO) wasted investments
> (into development-tools and the time into not that easily
> portable code-bases).
>
Execept you are completely blowing the situation out of proportion.
>> A year to learn html5/js? You must mean in depth expertise -
> Of course in depth, what else?
>
> I see Browsers (in their latest, much faster and more capable
> incarnations) as a new kind of (platform-independent) "Runtime" -
> finally and nowadays working fast enough even on all kind
> of different mobile-devices.
>
> A Runtime which is not distributed in "a Dll" (or multiple Dlls),
> but as a "hosting-process" (along with Dlls). A Host, which is
> offering an empty "Window" (an empty "Form") - but one you can
> "interact with"... the developer then responsible (as for any
> "empty classic VB-Form"), to bring life into it, using Controls
> or Widgets (a lot of them already built into the "Browser-Runtime",
> implemented in C/C++) ... + a glue language (JS) which currently
> runs already faster than VB6-PCode.
> Not *all* that much different to the concept we used over the
> last 15 years - it's only the loading-process of the "application-
> code" and the (GUI)resources (done over sockets instead using the
> FileSystem) which differs, but that one is not all that difficult
> to understand and adapt to - and it has advantages too, because
> you get machine-crossing RemoteProcedureCall-capabilities this
> way "for free".
>
>
> [usefulness of lambdas]
>
> You gave a poor example again, since it can be
> replicated in less lines of code in VB6:
>
Holy crap... are you purposefully being dense? It wasn't supposed to
be anything but a small example of how lambda's work. Not a canonical
example of when you would use them... For cripes sake, I could do the
same thing you did - and would for such a trivial case.
<snip>
> And it is even more maintenance-friendly, since
> you have to introduce a new "MathOp" only in the
> Enum and with one additional line in the Select Case
> construct - whereas your example would require changes
> in three places.
>
> The VB-example has (furthermore) the advantage, to
> work not only with integers, but with any numeric
> type - and if you want to restirct it to only one
> certain allowed type, you could do so of course.
>
LOL.. yeah, by using a variant. yuck! I can do the same in C# - using
object. I just chose not to for a TRIVIAL example.
> Also your .NET example needs more memory, because
> you introduced a Dictionary-Instance quite unnecessarily.
>
> There are better lambda-examples out there
Of course there are. That wasn't the point of the example. It's not
like I have time to spend hours writing tivial little apps for news
groups.
> - but this
> may serve as an example to what I said earlier -
> most of your advertised .NET-features serve (for a
> mid-level programmer as yourself) only as a vehicle
> "to feel better" - their usage at such a skill-level
> is mostly questionable and often inefficient.
>
You take a trivial example, and then extrapolate this crap?
> [simple ListBox-triggered MediaPlayer-example]
>> There you go - your nasty code made working in .net.
>
> "Nasty" is a matter of taste - I find also your revised
> example still "too wordy" for mine...
>
Turn of option strict, and it's even closer. Yes, the event handeling
is different - but, of course just like in VB6 - you don't type that.
--
Tom Shelton
[toc] | [prev] | [next] | [standalone]
| From | "Henning" <computer_hero@coldmail.com> |
|---|---|
| Date | 2012-05-26 23:31 +0200 |
| Message-ID | <jpri3t$pbq$1@dont-email.me> |
| In reply to | #1129 |
"Tom Shelton" <tom_shelton@comcast.invalid> skrev i meddelandet
news:jprdft$t7n$1@dont-email.me...
> Schmidt explained :
>> Am 25.05.2012 18:12, schrieb Tom Shelton:
>>
>>> And, yes if ms kills the legacy desktop -
>>> then a "windows forms" app will stop working.
>>>
>>> But, as usuall you miss the point.
>> Ok, let's see who's missing the point.
>>
>>> It's about choices and options. And, leanring VB6 leaves you none.
>>> Excpet to be stuck in the legacy desktop, 32-bit world.
>>
>> So, if MS *is* killing the classic-desktop over the next years,
>> then you would have to rewrite your VB6-App... In the same
>> way, as you would have to rewrite your .NET 2.0 Winforms-App
>> (not much in a Winforms-App that "maps" directly to
>> Metro-WPF/WinRT or HTML5/JS, is there?).
>>
>
> Most of the .net framework is availabe in a metro app. The main stuff
> that changes are mostly file system access, network stuff, and of course,
> p/invoke.
>
> So, if you do a app in the correct way - you will not be rewriting the
> entire app. Mainly the interface, and replacing the bit of functionality
> that isn't availabe to you in metro.
>
>> So, why start with .NET 2.0 (your recommendation) at all,
>> when the VB6-Coding is easier done, and has less deployment-
>> problems?
>>
>
> LOL.. How do you know there are less deployment problems? If the .net 2.0
> or above framework is present - than there is no problem. It's an xcopy
> deploy. And, again - the chances are that it is there.
>
> And the coding is no harder than in vb6. It's in fact almost identical if
> you turn off option strict.
>
>>> My recomendation was actually not to use any VB.
>> But you do realize, that this group is a VB-group?
>>
>
> So?
>
>>> But, learning vb.net is clearly going to be better alternative
>>> to a language whose toolset is unsupported and dead in the market.
>> As long as "the market" (the markets platform) is the Windows-
>> Desktop, then VB6 "is still in it" - very much alive and
>> kickin, as long as this markets platform (Win32-API and COM)
>> is a given (and this will be the case until MS pulls the plug,
>> and starts with the same restrictions also on x86-Hardware,
>> as we see it done currently - only for the ARM-target).
>>
>> And as for "dead in the market" (if you really want to go there),
>> .NET 2.0 + Winforms already *is* dead - an early .NET-adopter
>> *will* have to rewrite his deprecated .NET 2.0 GUI-Applications
>> for the entirely different animal WPF.
>>
>
> Again, your missing the point. Yes, they will have to rewrite the gui -
> and maybe the whole app if they were stupid about how it was structured...
>
> I would whole heartedly suggest taht they just write the thing using wpf
> from the begining - if they could be assured of at least a .net 3.0
> environment. But, the goal was:
>
> 1) to learn the language
> 2) learn the framework
> 3) minimize the possiblity of having to deploy the framework.
>
> Personally, if I was the OP - I would just get with the IT people and find
> out what is part of the standard image. And, then either do some other
> platform if no .net (and that other would NOT be vb6) or target the latest
> version they support. But, by just targeting 2.0 they are pretty well
> assured that it will be there.
>
>> So, MS has "done it again" - Code-Investments destroyed -
>> now one is "encouraged" (and you yourself among the
>> marketeers) to "rewrite stuff again", to fit the shiny
>> new WinRT/WPF-paradigm.
>>
>
> I don't have to re-write hardely anything... So, not sure what your
> talking about. Most of my stuff will work unchanged - other than the UI.
> I don't tend to write monolithic apps.
>
>> And how long will *that* last might I ask... when there's
>> already an alternative way offered by MS themself
>> ("written in huge letters on the wall", so to say) -> HTML5/JS...
>>
>
> LOL.. That is pretty limited in metro. Most serious apps are going to be
> C++/C#/VB.NET + WPF.
>
>> So, .NET 2.0 + Winforms is dead
>
> Has been for a long time. In fact, Winforms has been in maintenance mode
> since .net 3.0.
>
>> - Code-Investments (you
>> strongly encouraged us to do over the last years) are
>> blown to pieces in this special .NET-camp, dejavu again...
>
> LOL... What a load of bs. Some inteface changes - yes. But, almost all
> of my code will go straight to metro. Because most of my logic is in
> their own libraries... And most of the .net framework is available in
> winrt.
>
>> So, if you ask me, I see the same thing happen in a few
>> years, with code-investments nowadays done into .NET/WPF
>> (when MS will switch entirely over to the new upcoming
>> star HTML5/JS).
>>
>
> They are not switching entirely to that. Please - stop exagerating.
> There is absolutely no indication that anything of the sort will happen.
>
>> But yes, VB6-users will have to switch too
>
> Who's the too? I don't have to switch to anything.
>
>> at some point in
>> time (over the next 5 years) - but they can take a good
>> look in the next 2 years, where the MS-journey takes the
>> "adventurous" (as yourself). VB.classic-users will perhaps
>> port those of their Applications which worth it, to HTML5/JS
>> directly, using the better and better becoming tools which will
>> evolve around that *platformindependent* paradigm - and they
>> will finally have ported only *once* - whereas the ".NET shops"
>> (if those follow along your path of thinking), will have ported
>> their VB6-Apps 2 times more:
>> 1. from VB6 to .NET Winforms
>> 2. from .NET Winforms to .NET WPF(+WinRT)
>> 3. from .NET WPF/WinRT to HTML5/JS finally
>>
>
> Wow. I thought you were smarter than that. Why do you feel the need to
> exagerate. .NET is still as much a part of WinRT - there are some changes
> yes - but, for the most part, things will just work. The main porting
> will be you gui logic - if you havent' already adopted wpf (it's been
> around for a # of years already).
>
>> I hope you get it now, even when you have a slight disadvantage
>> in understanding (because you're not self-employed, you just
>> receive your monthly paychecks) - so you perhaps never had to
>> spend money yourself for these (IMO) wasted investments
>> (into development-tools and the time into not that easily
>> portable code-bases).
>>
>
> Execept you are completely blowing the situation out of proportion.
>
>>> A year to learn html5/js? You must mean in depth expertise -
>> Of course in depth, what else?
>>
>> I see Browsers (in their latest, much faster and more capable
>> incarnations) as a new kind of (platform-independent) "Runtime" -
>> finally and nowadays working fast enough even on all kind
>> of different mobile-devices.
>>
>> A Runtime which is not distributed in "a Dll" (or multiple Dlls),
>> but as a "hosting-process" (along with Dlls). A Host, which is
>> offering an empty "Window" (an empty "Form") - but one you can
>> "interact with"... the developer then responsible (as for any
>> "empty classic VB-Form"), to bring life into it, using Controls
>> or Widgets (a lot of them already built into the "Browser-Runtime",
>> implemented in C/C++) ... + a glue language (JS) which currently
>> runs already faster than VB6-PCode.
>> Not *all* that much different to the concept we used over the
>> last 15 years - it's only the loading-process of the "application-
>> code" and the (GUI)resources (done over sockets instead using the
>> FileSystem) which differs, but that one is not all that difficult
>> to understand and adapt to - and it has advantages too, because
>> you get machine-crossing RemoteProcedureCall-capabilities this
>> way "for free".
>>
>>
>> [usefulness of lambdas]
>>
>> You gave a poor example again, since it can be
>> replicated in less lines of code in VB6:
>>
>
> Holy crap... are you purposefully being dense? It wasn't supposed to be
> anything but a small example of how lambda's work. Not a canonical
> example of when you would use them... For cripes sake, I could do the
> same thing you did - and would for such a trivial case.
>
> <snip>
>
>> And it is even more maintenance-friendly, since
>> you have to introduce a new "MathOp" only in the
>> Enum and with one additional line in the Select Case
>> construct - whereas your example would require changes
>> in three places.
>>
>> The VB-example has (furthermore) the advantage, to
>> work not only with integers, but with any numeric
>> type - and if you want to restirct it to only one
>> certain allowed type, you could do so of course.
>>
>
> LOL.. yeah, by using a variant. yuck! I can do the same in C# - using
> object. I just chose not to for a TRIVIAL example.
>
>> Also your .NET example needs more memory, because
>> you introduced a Dictionary-Instance quite unnecessarily.
>>
>> There are better lambda-examples out there
>
> Of course there are. That wasn't the point of the example. It's not like
> I have time to spend hours writing tivial little apps for news groups.
>
>> - but this
>> may serve as an example to what I said earlier -
>> most of your advertised .NET-features serve (for a
>> mid-level programmer as yourself) only as a vehicle
>> "to feel better" - their usage at such a skill-level
>> is mostly questionable and often inefficient.
>>
>
> You take a trivial example, and then extrapolate this crap?
>
>> [simple ListBox-triggered MediaPlayer-example]
>>> There you go - your nasty code made working in .net.
>>
>> "Nasty" is a matter of taste - I find also your revised
>> example still "too wordy" for mine...
>>
>
> Turn of option strict, and it's even closer. Yes, the event handeling is
> different - but, of course just like in VB6 - you don't type that.
>
> --
> Tom Shelton
>
>
Hi Tom, are you absolutly sure your middle name isn't Dotnet? ;)
/Henning
[toc] | [prev] | [next] | [standalone]
| From | "Mayayana" <mayayana@invalid.nospam> |
|---|---|
| Date | 2012-05-26 18:07 -0400 |
| Message-ID | <jprk4h$5bo$1@dont-email.me> |
| In reply to | #1130 |
| Hi Tom, are you absolutly sure your middle name isn't Dotnet? ;) | It should also be noted that Tom is not really interested in Windows software in the first place. He's not just choosing .Net over compiled software. He's moving to the Metro sandbox, out of the PC. He noted that "most of his code will go straight to Metro" without requiring rewrite. This group and this thread are specifically about Windows software. He's advising from his own point of view, which is writing WinPhone trinkets, with no interest in even the most basic PC factors, like a file system, while the OP's task was to put a list of files into a listbox for organized access.
[toc] | [prev] | [next] | [standalone]
| From | Tom Shelton <tom_shelton@comcast.invalid> |
|---|---|
| Date | 2012-05-26 16:50 -0600 |
| Message-ID | <jprmne$io1$1@dont-email.me> |
| In reply to | #1131 |
Mayayana brought next idea : >> Hi Tom, are you absolutly sure your middle name isn't Dotnet? ;) >> > > It should also be noted that Tom is not really interested > in Windows software in the first place. He's not just choosing > .Net over compiled software. He's moving to the Metro > sandbox, out of the PC. He noted that "most of his code will > go straight to Metro" without requiring rewrite. This group and > this thread are specifically about Windows software. He's > advising from his own point of view, which is writing WinPhone > trinkets, with no interest in even the most basic PC factors, > like a file system, while the OP's task was to put a list of files > into a listbox for organized access. Hey dummy - metro is windows software. Sorry, you just have a very narrow interpretation of reality. -- Tom Shelton
[toc] | [prev] | [next] | [standalone]
| From | "Mayayana" <mayayana@invalid.nospam> |
|---|---|
| Date | 2012-05-26 20:53 -0400 |
| Message-ID | <jprtrd$pt1$1@dont-email.me> |
| In reply to | #1132 |
| Hey dummy - metro is windows software. Sorry, you just have a very | narrow interpretation of reality. | You can call it that if you want. Microsoft is calling it part of Windows 8. But that doesn't make it so. Personally I like to work on Windows software. I have no interest in writing sandboxed trinkets, optimized for WinPhone8, that can't actually run on Windows itself and can't even be installed except by permission through Microsoft's online store! I'm not even mildly curious. You're hanging around in a Windows programming group telling people that they're using the wrong tool because they won't be able to use it for WinPhone apps!
[toc] | [prev] | [next] | [standalone]
| From | Tom Shelton <tom_shelton@comcast.invalid> |
|---|---|
| Date | 2012-05-26 20:31 -0600 |
| Message-ID | <jps3li$jgu$1@dont-email.me> |
| In reply to | #1133 |
Mayayana wrote on 5/26/2012 : >> Hey dummy - metro is windows software. Sorry, you just have a very >> narrow interpretation of reality. >> > > You can call it that if you want. Microsoft is > calling it part of Windows 8. But that doesn't > make it so. > > Personally I like to work on Windows software. > I have no interest in writing sandboxed trinkets, > optimized for WinPhone8, that can't actually run > on Windows itself Uh, well not true if the rumors of winphone 8 are true. > and can't even be installed > except by permission through Microsoft's online > store! I'm not even mildly curious. > > You're hanging around in a Windows programming > group telling people that they're using the wrong > tool because they won't be able to use it for > WinPhone apps! LOL.. That's not what I said, but you know that. All I said was that learning VB.NET gave the OP options to do so if they desired. Not that they had to, or that they even should. -- Tom Shelton
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.lang.basic.visual.misc
csiph-web