Alternatives
in [Visual Basic]
|
From: expvb on 13 Jan 2009 22:16 "Ulrich Korndoerfer" <ulrich_wants_nospam(a)prosource.de> wrote in message news:efSQPVfdJHA.3488(a)TK2MSFTNGP05.phx.gbl... > Hi Olaf, > > Schmidt schrieb: > >> Yep, one can use either McKinneys Typelib - or some >> newer pendants to it, which are available after a short Google- >> session. > > And the Google search phrase would be ? I am not sure if this is the same library, but here is one for many API functions, and it includes the source: http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=62060&lngWId=1
From: Ulrich Korndoerfer on 13 Jan 2009 22:45 Hi, expvb schrieb: >> >>> Yep, one can use either McKinneys Typelib - or some >>> newer pendants to it, which are available after a short Google- >>> session. >> And the Google search phrase would be ? > > I am not sure if this is the same library, but here is one for many API > functions, and it includes the source: > > http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=62060&lngWId=1 thanks. I do have the McKinney typelib and also the Appleman version. But both are rather old. Your example also is about 3 to 4 years old. And all are the work of a single man. I'd prefer the typelib being maintained and build by a community. Reasons are: should be up to date, and, more important, should be mostly correct because a community has more eyes than a single developer. I suspect that the Wine project could offer such but did not have any success in finding one. It has always been a pain for me to step through open source projects wep representations in search for something. Mostly even searching MS gives me more success ;-) Nowadays there are many open source language projects out there, that have libraries wrapping calls to the windows api, eg Perl, Ruby, Python, and so on. But as far as I can say, the libraries are build to facilitate the api use from their language, and no one thought of making the api calls available via typelibs. There must have been lots of work put into those libraries, but no one seemingly did the extra work to produce a typelib as a "byproduct". Btw, it is a shame that until now MS does not deliver a WIN32 Api typelib on their own. -- Ulrich Korndoerfer VB tips, helpers, solutions -> http://www.proSource.de/Downloads/
From: Bee on 14 Jan 2009 01:28 Thanks all for a lot to chew on. "Bee" wrote: > Me - diehard VB6 user. > My friends - wanting to learn to program apps for Windows. > So what about > RealBasic > Delphi > PowerBasic > What would be easiest for me (in case I get involved in the other language) > to provide sample VB6 source to them and have them learn from my examples in > one of the three mentioned or for that matter any other non-MS product? > Which one is sophisticated enough to support complex applications? > i.e. something worth really getting into. > Thanks. >
From: Schmidt on 14 Jan 2009 13:37 "Ulrich Korndoerfer" <ulrich_wants_nospam(a)prosource.de> schrieb im Newsbeitrag news:OwtsPqfdJHA.1532(a)TK2MSFTNGP03.phx.gbl... > >>> Yep, one can use either McKinneys Typelib - or some > >>> newer pendants to it, which are available after a short Google- > >>> session. > >> And the Google search phrase would be ? Sorry for the late response... I've used for some time: http://sourceforge.net/projects/win32apilib/ (last changes in July 2005) IIRC the author [SolarAngel] was also active in these groups. > I'd prefer the typelib being maintained and build by a community. Yep - another nice project that would be... :-) > Btw, it is a shame that until now MS does not deliver a > WIN32 Api typelib on their own. Ack. Olaf
From: Schmidt on 14 Jan 2009 14:56
"Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> schrieb im Newsbeitrag news:%23Tbc22ddJHA.3488(a)TK2MSFTNGP05.phx.gbl... [Threading] > The point is, that this is a much simpler thing to do in .NET. Ok, think you can prove that within your .NET-pendant of the simple Threading-Demo... ;-) > >> 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. Yep - in the same way as we have that in VB6 - in VB6 it is a bit easier to write (automatically) synchronized threading- code when OLE-Marshaling is used - and (only a little bit) more lines of code are required, when it comes to shared memory-scenarios. > >> 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. That's your opinion - if you found your tool of choice - then I have no problems with that - what I know is, that one usually gets better and better (and more productive) over time, when he does not change his tool of choice at "each occassion" - e.g. my learning-curve with VB- Classic has yet enough room for another few years of "climbing". ;-) > > 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. The initial-release was planned for this time (early january), but I decided, to rewrite everything I had already finished (with plain Win32-GDI-calls) with a new cairo-based rendering- backend, which currently works out as a really good decision. > It is P/Invoke - but .NET types have to be converted to > native types, this process is called Marshalling. Ah - Ok. > >> 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. Which is nonetheless simply there and very useful - if it wouldn't have been available in VB-Classic directly, then there'd have been appropriate API-Wrappers or Typelibs for getting access to the Pointers or VBs VarTypes. > >> 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 Going through what ...- with the Win32API.tlb here on my machine I wouldn't have to write anything for the W-Function of GetWindowText - and the A-Version is copyable from the builtin VB6-APILoader-Addin. For those who prefer 10-20 MouseClicks, to define the Parameters in a Treeview - and choose the Parameter-Types from a ListControl (as offered by the Curland-Tool) I also don't see "huge hurdles". All others could also write something like that into a VB6- *.bas-Module: Public UseANSI As Boolean Declare Function GetWindowTextW Lib "user32" ( _ ByVal hWnd As Long, ByVal lpString As Long, _ ByVal nMaxCount As Long) As Long Declare Function GetWindowTextA Lib "user32" ( _ ByVal hWnd As Long, ByVal lpString As String, _ ByVal nMaxCount As Long) As Long Function GetWindowText(ByVal hWnd As Long) As String Dim S As String: S = Space$(260) If UseANSI Then GetWindowText = Left$(S, GetWindowTextA(hWnd, S, Len(S))) Else GetWindowText = Left$(S, GetWindowTextW(hWnd, StrPtr(S), Len(S))) End If End Function And this small implementation comes without TypeLibs and offers already a complete encapsulation of both APIs, switchable even at runtime. And yes, over your Auto-Option you save some LOC in this case, agreed - but the VB6-Code-Duplication for the W-Part can mostly be done with a simple Copy'nPaste and the String- Type-change, really not much "own typing effort" needed, to enhance an ANSI-Version about additional W-support. But normally one decides, to use only one version throughout his Apps - for newer ones I only use the W-Functions. Potential Win98-Users (the non SE-Version) would then need to install the downloadable UniCode-Layer, but if they run Office or a newer IE-Version on their old Win98- Machines, then it is normally already there. > >> >> 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. Stumbled over this link already some time ago, sorry for using the original Authors words - but I've only "looked over it" - and therefore used "as it seems" in my first statement. And I seriously don't really care, if variant-support is included in .NET or not... ;-) > No body want's variant. We have system.object for the > cases where you need it. If the Object-Serialization from .NETs Base-Object-Types is fast enough in RPC-scenarios, then all is well. For the Variant-Serialization I've built into my RPC-communication routines I can say, that these work really fast, comparable to the OLE-Variant-Marshaling - and at least SOAP-communication is ways slower than that. I don't want to switch the topic this way, but that's just one case I could think of, which maybe brings back such an universal DataContainer into the ..NET-world - simply because of performance-reasons. I mean - is the Main-Transaction-Monitor for high throughput yet based on COM+ and OLE-Variant-Marshaling in the ".NET-enterprise-world" or not? [Runtime-Sizes and the 1MB-VB-Runtime] > Yeah, and back in the late 90's that was considered huge > because every one was on slow dialups. > > How times change. Yep, nowadays one can download the VB6-Runtime from the MS-site in ca. 10 seconds and install it per doubleclick in another 5 seconds. For the newest 3.5(1) Framework-install of .NET (which I had to, because of the small "challenge" I've already mentioned) I needed ca. 15 minutes for the Download - and another 12 Minutes, until the install- process was finished (including a reboot of my machine which was required for some reasons). Hmm, some things don't really 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. Here's something like a task-description (maybe yahoo-babelfish will do for you) - and the .NET code which was written (automatically generated code was not counted). http://www.informtools.de/kb.aspx?ID=350 The VB6-pendant is downloadable here: www.datenhaus.de/Downloads/VB6UniDemo.zip Please take a look at the dependencies in register.bat, before clicking on it - most of the small (freeware) Unicode-Controls shouldn't be on anyones machine - (and therefore cannot conflict)... but maybe the Uni-FlexGrid-light from Component- One is preinstalled on your dev-machine(s) - then remove that entry before you start register.bat, to not mess around with your own Flex-Registrations. Also required is VBs DatePicker.ocx - but I've not included that in register.bat for the same reasons as with the FlexGrid - this control should be there on a VB6-machine. These Demos look (and do) nearly identically - mainly this is a typical master-detail-approach with some special Filter-requirements (filtered records had to be colored in the grid) - and updates from other users, changing DB-content which the "slower user" was also changing, had to be "marked" and coloured in the grids too. The .NET-version was using LINQ and a JET-backend, the VB6-version an SQLite-backend (a special feature of the VB6-Version is, that it already implements also a "fully scalable" Appserver-mode for the same SQLite-backend - one can choose between Desktop-DB and Appserver-Mode on startup). Don't know, if that helps you along - but I don't have time the next days or weeks, to elaborate too much about these examples - nonetheless the VB6-Version could be useful for others, which want to start to explore SQLite and/or my framework - I've therefore changed the Binaries in this Demo to the most current Beta3-Version of my new upcoming version, which contains some new features for SQLite (persistable Command-Objects and nested Transactions over named SavePoints) compared with the former version in this Demo - the wiring-Code in the Demo was of course not changed. Olaf |