Post by SchmidtPost by Tom SheltonPost by SchmidtWhen 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.
Post by SchmidtSo 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.
Post by SchmidtBecause 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.
Post by SchmidtPost by Tom SheltonC++ 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.
Post by SchmidtPost by Tom SheltonThis 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.
Post by SchmidtAnd 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.
Post by SchmidtIf 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.
Post by Schmidt[Threading]
Post by Tom SheltonYou'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".
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.
Post by SchmidtHe 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.
Post by SchmidtHe'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...
Post by SchmidtPost by Tom SheltonWhy, 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.
Post by Schmidtwhich 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.
Post by SchmidtYou 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.
Post by SchmidtAs 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.
Post by SchmidtSo 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.
Post by SchmidtThe future tools (for me) lay elsewhere.
Cool.
Post by SchmidtYou 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.
Post by SchmidtPost by Tom SheltonIf 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.
Post by SchmidtWhat 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.
Post by SchmidtWhat 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.
Post by Schmidtwill 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.
Post by SchmidtI'd be really careful with this last move of MS
(with regards to investing my time) ... same thing
as I did with .NET...
'***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 :)
Post by SchmidtThe 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.
Post by SchmidtFurthermore, 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