Bring back Classic Visual Basic

[admin]

This is not off-topic since XY is written in VB. It looks like there is a chance that MS will turn their focus back to the best tool they have ever designed: VB. Good timing, since recently even I find myself thinking about moving to .NET (which would happen only at incredible costs in money and time, and at a severe loss in development speed ).

So, you could help the cause by voting on this page (each person can put 3 votes!):
http://visualstudio.uservoice.com/forum ... oved-versi

It would be really good for XYplorer...

Don

[Marco]

Done!

PS: could you please explain the move towards .NET? Now XY can handle 64bit menus (albeit non natively). What would bring .NET, besides a native 64bit executable? And why not shifting to C++?

[klownboy]

Done

[yusef88]

done

[serendipity]

So, you could help the cause by voting on this page (each person can put 3 votes!)...

Done, 9 votes (using 3 email addresses!)

[admin]

PS: could you please explain the move towards .NET? Now XY can handle 64bit menus (albeit non natively). What would bring .NET, besides a native 64bit executable? And why not shifting to C++?

1) Indeed, things look very different now than some weeks ago. We have 64bit menus, and I know much more about NET and about the costs of migration.
2) Too slow.

[40k]

If I was a Windows developer right now I wouldn't know which way to turn. You can't really trust Microsoft anymore to do the right thing. .NET 1.0 introduced somewhere around 2002, support already dropped by 2009. How are you supposed to build an application on such a shifting platform.

[admin]

I guess C++ is a pretty safe bet, but this language is not apt to rapid application development, its focus is somewhere else. VB is/was THE language exactly made for this. Some demon got MS off track. Hopefully they find back to reason.

[Marco]

1) Indeed, things look very different now than some weeks ago. We have 64bit menus, and I know much more about NET and about the costs of migration.
2) Too slow.

So why migrating? AFAIC understand, no bitness will give XY a "full" 32+64bit context menu (only Windows shell can do this). So, what else will give NET that VB doesn't already give you/us?

[avsfan]

Done! 5 email addresses = 15 votes!

[Enternal]

Done!

1) Indeed, things look very different now than some weeks ago. We have 64bit menus, and I know much more about NET and about the costs of migration.
2) Too slow.

So why migrating? AFAIC understand, no bitness will give XY a "full" 32+64bit context menu (only Windows shell can do this). So, what else will give NET that VB doesn't already give you/us?

One thing I can think of right away if multi-threading. That will be extremely helpful. Even with Don's magic coding, there are many times I can see that multi-threading would be an immense help to the way XYplorer handle things.

The other thing is, we now have 2 extra executable that comes with XYplorer. XYCopy for copy and move and the executable for 64bit menu. If VB6 was multi-threading and support 64bit, there would never be 2 extra executable that are shipped with XYplorer.

EDIT: I do however think that perhaps XYCopy should remain separate. The reason is that xplorer2 is also multi-threaded yet if it crashes, it takes the whole thing with it. I once had a file operation going on and I was doing something in xplorer2 and it crashed... so did the copy operation thread. I can see benefits in having a separate executable for the copy process. Either way, having it multi-threaded will still be useful. Even with a separate process XYCopy, XYplorer definitely feels slower or lags a bit sometimes while XYCopy is working.

[JohnM]

Done

[xycooper]

Done.

[Mesh]

Done.

[admin]

Thanks for all the "Done"s!