Alternatives
in [Visual Basic]
|
From: Schmidt on 13 Jan 2009 18:23 "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> schrieb im Newsbeitrag news:e7zuEqcdJHA.5412(a)TK2MSFTNGP04.phx.gbl... > >> That is true. But, there are limitations in VB.CLASSIC's > >> threading. It is not free-threaded, and there for hacks are > >> required to transfer data accross thread boundries (TLS). > > No, absolutely not - that's one of the nice things with > > AX-Exe-Threading - the transfer of data across TLS- > > boundaries works entirely transparent - over the same > > COM-Interfaces which you would use singlethreaded - > > and this even fully synchronized - without forcing you > > to write the synchronization-code yourself. > > > > Sure - unless your tyring to share the data. Try it out. I do this all the time - e.g. in my multithreaded working AppServer-Implementation in dhRichClient.dll. Working with shared memory is not a hack - that's the way it works (on top of the automated TLS-marshaling - in case one want's to use that too in his VB6-Threads). > A change to a value in one thread, is not reflected in > another thread. Each thread gets their own copy of any > data Yes - and as said - on top of that you can also span a shared memory area and transfer the Pointers to that area into the threads which need to communicate or exchange Data this way. > TLS is nice, if your threads do not need to interact - but, > becomes a hinderance when they need to share resources. No hinderance - one can bypass the OLE-Threadmarshaler at any time - but then has to ensure the synchronization on these shared memory-resources himself - in much the same way as in .NET or C/C++ (e.g. over critical sections). > New things are always being added. When is it going to be > the right time? Exactly - and I'd say it is not (yet) the right time, to move too fast away from the yet very competitive VB6-RAD- environment. It works well and fast (as IDE) on all current Win-Platforms and the Binaries (and probably the VB-Classic-IDE too) seem to run for at least another 5 years even on windows7. > But, if you did wait - this is a good time :) WPF is a > really nice technology. Will post an announcement regarding a WPF-pendant for VB6 soon here in the group. [Marshaling of (Win)API-calls] > But I wasn't talkign about COM componets. We were > specifically talking about calls to native api's. Ok, didn't know that the term 'marshaling' in .NET is apparently used for calls against "classical Dlls" as the WinAPI for example - until now I've known these calls as .NET-PInvoke-Calls. > And they are hacks - for many years, StrPtr wasn't > even a documented function... But it's usage doesn't make my implementations a "hack", really ... in C or C++ you are using the BSTRs(Ptrs) normally in this way - and no one calls your code a "hack" when you work with these Pointers. > And to use a typelib, you either have to find > one that already exists or dive into learning IDL. Yep, one can use either McKinneys Typelib - or some newer pendants to it, which are available after a short Google- session. And then there's of course Curlands TypeLib-Editor - which comes with his book - and works really easy and nice for IDL-inexperienced users. > Yes - if your willing to step outside of VB and learn to use IDL. As said, there are Win32-API-Tlbs out there (including the W-Functions) - and one has not to code IDL directly, if he uses the Curland IDE-Plugin for VB-Classic - this offers a Point-and-click-Interface to define your TypeLib-implemented Calls. [Unions] > Hmmm... How 'bout the console api? Not often needed (at least by me) - but I know some good (and free) libraries for VB-Classic, which already encapsulate these APIs in a nice way - no need to code that myself when I ever should need that. > >> VB.NET has optional params as well ;) > > In the meantime, yes - that's a nice feature - and > > also the Variant-Type is back again as it seems. > > No it's not. I assume your talking about type inference - > this is NOTHING like Variant. And it can be turned off. Not exactly like a real Variant, yes ... http://www.igloocoder.com/archive/2007/03/17/1028.aspx - too sad, that you cannot change such a type at runtime (this is more a PreCompiler-thingy) - you would have to use .NETs generic Object-Type for scenarios where this is needed. But just wait a bit, there's always hope... <g>. [usage of libraries] > Really. Hmmm... 3rd party tools created specifically to > overcome limitations in the language and ide are not work > arounds. Exactly - these things are called libraries. ;-) And VB6 is/was always thought as a "wiring"-tool for external (mainly COM-) libraries - either built from your own sources - or from 3rd-party-vendors. Only .NET follows (Ok, Java too) the philosophy, to include everything but the kitchen-sink in the "standard- runtime". What about other languages then (and all the Apps, which are coded in C/C++/Delphi-Win32) ... as soon as those start to use the WinAPI or external libs (or frameworks), do they use "workarounds"? ... interesting stuff all that... ;-) > > is, that in .NET the huge library is a "must-dependency" - > > where in VB6 I have the choice, which lib(s) I use and > > include in my deployment. > > The VB6 runtime is a must dependency as well... Currently preinstalled on all WinVersions - and as it seems also on Windows7 - that's really no argument - beside that - it is ca. 1MB. > But, I will give you this point. VB6 can have a significantly > smaller distibution foot print... Still, I find that the productivity > gains far outweigh this one minor issue :) We recently had a discussion about these miraculous ".NET- productivity-gains" in the german VB6-group. And at least regarding lines of code (for a similar scenario - once implemented in VB6 - and on the other hand implemented in VB.NET, based on the new framework-version 3.5(SP1), including LINQ-features, since that was mentioned as a huge productivity-boost - the .NET-result was a bit disappointing - it was needing ca. 15% more lines of code, compared with the VB6-solution - and this was an Unicode-DB-scenario which had to be covered - and the "demand" for this little "challenge" came from the ..NET-side which tried really hard, to include requirements, VB6 had not to offer "out of the box". > I would do it in VB.NET - but, I just don't do much > work in that anymore. I'm afraid, I wouldn't be a good > representitive of the language :) No problem - just try to reach less lines of code than the VB6-solution... (and of course a better performance) <g>. Olaf
From: Tom Shelton on 13 Jan 2009 19:19 On 2009-01-13, Schmidt <sss(a)online.de> wrote: > > "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> schrieb im Newsbeitrag > news:e7zuEqcdJHA.5412(a)TK2MSFTNGP04.phx.gbl... > >> >> That is true. But, there are limitations in VB.CLASSIC's >> >> threading. It is not free-threaded, and there for hacks are >> >> required to transfer data accross thread boundries (TLS). >> > No, absolutely not - that's one of the nice things with >> > AX-Exe-Threading - the transfer of data across TLS- >> > boundaries works entirely transparent - over the same >> > COM-Interfaces which you would use singlethreaded - >> > and this even fully synchronized - without forcing you >> > to write the synchronization-code yourself. >> > >> >> Sure - unless your tyring to share the data. Try it out. > I do this all the time - e.g. in my multithreaded working > AppServer-Implementation in dhRichClient.dll. > Working with shared memory is not a hack - that's the > way it works (on top of the automated TLS-marshaling - > in case one want's to use that too in his VB6-Threads). > >> A change to a value in one thread, is not reflected in >> another thread. Each thread gets their own copy of any >> data > Yes - and as said - on top of that you can also span > a shared memory area and transfer the Pointers to that > area into the threads which need to communicate or > exchange Data this way. > Yes. You have to pass pointers - but when you do that, well then you have to do the sync your self. Look, I've written threaded servers in VB6 - I'm well aware of how to do it (well, at least I used to be - I haven't touched VB6 seriously since 2002)... The point is, that this is a much simpler thing to do in .NET. >> TLS is nice, if your threads do not need to interact - but, >> becomes a hinderance when they need to share resources. > No hinderance - one can bypass the OLE-Threadmarshaler > at any time - but then has to ensure the synchronization > on these shared memory-resources himself - in much the > same way as in .NET or C/C++ (e.g. over critical sections). > ..NET can use TLS as well. You can create threads as either STA or MTA. So, you have your choice. >> New things are always being added. When is it going to be >> the right time? > Exactly - and I'd say it is not (yet) the right time, to move too > fast away from the yet very competitive VB6-RAD- > environment. LOL... Not even close, IMHO. There is no doubt that VB6 was excelent for it's time, but it's time has come in gone for me. And, I am really glad. > It works well and fast (as IDE) on all current Win-Platforms > and the Binaries (and probably the VB-Classic-IDE too) > seem to run for at least another 5 years even on windows7. > >> But, if you did wait - this is a good time :) WPF is a >> really nice technology. > Will post an announcement regarding a WPF-pendant > for VB6 soon here in the group. > I'm anxious to hear about this. > [Marshaling of (Win)API-calls] >> But I wasn't talkign about COM componets. We were >> specifically talking about calls to native api's. > Ok, didn't know that the term 'marshaling' in .NET is > apparently used for calls against "classical Dlls" as the > WinAPI for example - until now I've known these > calls as .NET-PInvoke-Calls. > It is P/Invoke - but .NET types have to be converted to native types, this process is called Marshalling. >> And they are hacks - for many years, StrPtr wasn't >> even a documented function... > But it's usage doesn't make my implementations > a "hack", really ... in C or C++ you are using the > BSTRs(Ptrs) normally in this way - and no one calls your > code a "hack" when you work with these Pointers. > No - but C++ supports getting the pointers. StrPtr was an undocumented and unsupported function. >> And to use a typelib, you either have to find >> one that already exists or dive into learning IDL. > Yep, one can use either McKinneys Typelib - or some > newer pendants to it, which are available after a short Google- > session. And then there's of course Curlands TypeLib-Editor - > which comes with his book - and works really easy and nice > for IDL-inexperienced users. > And you somehow think that going through this is easer then: Declare Auto Function GetWindowText Lib "user32" ( _ ByVal hWnd As IntPtr, _ ByVal lpString As StringBuilder, _ ByVal nMaxCount As Integer) As Integer >> Yes - if your willing to step outside of VB and learn to use IDL. > As said, there are Win32-API-Tlbs out there (including the > W-Functions) - and one has not to code IDL directly, if he > uses the Curland IDE-Plugin for VB-Classic - this offers a > Point-and-click-Interface to define your TypeLib-implemented > Calls. > > [Unions] >> Hmmm... How 'bout the console api? > Not often needed (at least by me) - but I know some > good (and free) libraries for VB-Classic, which already > encapsulate these APIs in a nice way - no need to code > that myself when I ever should need that. > >> >> VB.NET has optional params as well ;) >> > In the meantime, yes - that's a nice feature - and >> > also the Variant-Type is back again as it seems. >> >> No it's not. I assume your talking about type inference - >> this is NOTHING like Variant. And it can be turned off. > Not exactly like a real Variant, yes ... > http://www.igloocoder.com/archive/2007/03/17/1028.aspx > It is not a variant. In C#, variables declared as var are strongly typed. 1) they can only be used local to a method 2) they have to be initialized at declaration Comparing it to a variant, really shows a misunderstanding of what it is. > - too sad, that you cannot change such a type at runtime > (this is more a PreCompiler-thingy) - you would have > to use .NETs generic Object-Type for scenarios where > this is needed. > Depends. If you need to store multple types in the same container, then yes. But, many times you can just use generics: VB.NET Dim myListOfNames = New List(Of String) Dim myDictionary = New Dictionary(Of Integer, Of String)() C# var myListOfName = new List<string>(); var myDictionary = new Dictionary<int, string>(); > But just wait a bit, there's always hope... <g>. > No body want's variant. We have system.object for the cases where you need it. > [usage of libraries] >> Really. Hmmm... 3rd party tools created specifically to >> overcome limitations in the language and ide are not work >> arounds. > Exactly - these things are called libraries. ;-) > > And VB6 is/was always thought as a "wiring"-tool > for external (mainly COM-) libraries - either built > from your own sources - or from 3rd-party-vendors. > > Only .NET follows (Ok, Java too) the philosophy, to > include everything but the kitchen-sink in the "standard- > runtime". > > What about other languages then (and all the Apps, > which are coded in C/C++/Delphi-Win32) ... as soon > as those start to use the WinAPI or external libs (or > frameworks), do they use "workarounds"? ... interesting > stuff all that... ;-) > You do make a good point - in that libraries are usually meant as language extensions. So, I'll give you that :) >> > is, that in .NET the huge library is a "must-dependency" - >> > where in VB6 I have the choice, which lib(s) I use and >> > include in my deployment. >> >> The VB6 runtime is a must dependency as well... > Currently preinstalled on all WinVersions - and as it seems > also on Windows7 - that's really no argument - beside that - > it is ca. 1MB. > Yeah, and back in the late 90's that was considered huge because every one was on slow dialups. How times change. >> But, I will give you this point. VB6 can have a significantly >> smaller distibution foot print... Still, I find that the productivity >> gains far outweigh this one minor issue :) > We recently had a discussion about these miraculous ".NET- > productivity-gains" in the german VB6-group. > And at least regarding lines of code (for a similar scenario - > once implemented in VB6 - and on the other hand implemented > in VB.NET, based on the new framework-version 3.5(SP1), > including LINQ-features, since that was mentioned as > a huge productivity-boost - the .NET-result was a bit > disappointing - it was needing ca. 15% more lines > of code, compared with the VB6-solution - and this > was an Unicode-DB-scenario which had to be covered - > and the "demand" for this little "challenge" came from the > .NET-side which tried really hard, to include requirements, > VB6 had not to offer "out of the box". > Well, with out seeing the code, or knowing what the task was, I certainly can't comment on it. I know the stuff I converted to VB.NET back in 2002-2003 usually ended up withe less code. But, I don't know that this is the case in all instances. >> I would do it in VB.NET - but, I just don't do much >> work in that anymore. I'm afraid, I wouldn't be a good >> representitive of the language :) > No problem - just try to reach less lines of code than > the VB6-solution... (and of course a better performance) > <g>. -- Tom Shelton
From: "Bill McCarthy" TPASoft.com Are Identity on 13 Jan 2009 19:48 "mayayana" <mayaXXyana(a)rcXXn.com> wrote in message news:eRmGPkbdJHA.4052(a)TK2MSFTNGP06.phx.gbl... >> > Hmm. Quickly? >> > One wonders what the framework is for >> >> You see I said for advanced stuff right? No framework can be all things > to >> all people. > > It's just that you tend to be a bit fast and loose in > the context of your arguments. I said VB.Net might be > good because the person wouldn't need to understand > Windows. Of course you need to understand Windows: jsut because an API is wrapped for you doesn't mean you can use it without knowing what it does and how it relates to windows. BTW: where would you put VBScript in that.
From: "Bill McCarthy" TPASoft.com Are Identity on 13 Jan 2009 19:53 "Schmidt" <sss(a)online.de> wrote in message news:OibVEWcdJHA.5540(a)TK2MSFTNGP05.phx.gbl... > >> >> 4. Support for overloading function calls. >> > Yep - that's nice - but Optional Params do well for me >> > so far. >> >> VB.NET has optional params as well ;) > In the meantime, yes - that's a nice feature - and > also the Variant-Type is back again as it seems. I think you are mistaken. Are you thinking of implicit typing ? That is design time/compile time strong typing, not "variant". In .NET, Object is and always has been the equivalent of Variant
From: "Bill McCarthy" TPASoft.com Are Identity on 13 Jan 2009 20:00
Hi Tom, "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> wrote in message news:%23Tbc22ddJHA.3488(a)TK2MSFTNGP05.phx.gbl... > > Declare Auto Function GetWindowText Lib "user32" ( _ > ByVal hWnd As IntPtr, _ > ByVal lpString As StringBuilder, _ > ByVal nMaxCount As Integer) As Integer > You can use ByVal lpString As String in VB.NEt and it will do safe copying (unicode or ansi based on platform). Just don't try that in C# withotu the addition of the VBByRefStr attrbiute. |