From: Schmidt on 14 Jan 2009 16:05
"Karl E. Peterson" <karl(a)mvps.org> schrieb im Newsbeitrag
Don't really know what to write Karl...
or if I already deserve something like a "Curland award" <g> -
maybe I can come near in two or three years, if everything
works out in a good way with "my plans" for VB-Classic. ;-)
But these ideas also depend a lot on the help of the
Classic-community, which I hope is yet strong -
and those who are willing to help to "move-on" (with) the
VB-Classic-environment, will probably wait for some
signals and encouragement also from "well-known
authorities" like yourself - hope I can count on you...
From: Tom Shelton on 14 Jan 2009 16:30
On 2009-01-14, Schmidt <sss(a)online.de> wrote:
> "Tom Shelton" <tom_shelton(a)comcastXXXXXXX.net> schrieb im Newsbeitrag
>> 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... ;-)
I started looking into it last night - the threading part is easy, it's the
drawing part that I have trouble with :) I really haven't had time yet to
work on it though. I think I'm going to, though, just as a learning
experience... But, it might be a few days...
>> >> 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
>> >> 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 api's that I use regularly, I wrap in a reusable dll. Then, when I need
it it's simply a matter of:
string windowText = User32.GetWindowText (hWnd);
In other words, I generally write wrappers and such - and never worry about it
again :) though, funily it looks like you do something similar from below.
> 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-
> 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)))
> 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.
I don't generally bother with Auto anymore myself. I useally just specify
Unicode - since nothing I write is ever going to be used on a 9x machine :)
>> >> >> 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).
> The VB6-pendant is downloadable here:
> 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.
I know what you mean.
From: Karl E. Peterson on 14 Jan 2009 19:33
> "Karl E. Peterson" <karl(a)mvps.org> schrieb ...
> Don't really know what to write Karl...
It was sincere. Just bask in it. :-)
> or if I already deserve something like a "Curland award" <g> -
> maybe I can come near in two or three years, if everything
> works out in a good way with "my plans" for VB-Classic. ;-)
> But these ideas also depend a lot on the help of the
> Classic-community, which I hope is yet strong -
> and those who are willing to help to "move-on" (with) the
> VB-Classic-environment, will probably wait for some
> signals and encouragement also from "well-known
> authorities" like yourself - hope I can count on you...
I'm in your corner. But probably not in your league! I'll definitely help to the
extent I can, which may even be more on the non-tech side of things. I've spent
nearly three decades as part of this community. Not gonna bail now! :-)
..NET: It's About Trust!
From: Ken Halter on 14 Jan 2009 21:54
"Bee" <Bee(a)discussions.microsoft.com> wrote in message
> Thanks all for a lot to chew on.
Here's another wad of chaw to relieve some of your cravings.
I just got this in the email yesterday. No time to check it out right now...
too busy looking for a damn job! He sent a link request, which I will gladly
At least it shows that we're not the only crowd around who thinks MS's
ruthless destruction of VB (along with sending their relentless dotnet
trolls here) was a mistake... funny.. if you take a look at the stock market
(overall), VB Classic's demise (as far as MS is concerned) may be
responsible for the shape of the global economy as we know it (stretching
things a bit, eh? <g>)
'==================Hello, since weeks ago I released a new project called
'Jabaco'. The target ofthis project is offering a BASIC programming language
for the Java VirtualMachine with a VB6-similar syntax. The Jabaco syntax
enhanced the VB6syntax with OOP-features like inheritance and polymorphism.
The project isfreeware with an open source framework (BSD). The software
comes with verymodern and powerful features like a graphical GUI-Designer, a
comfortableSource-Editor, a Runtime-Debugger, a VB6-Converter and several
other toolsto make your work easier. I hope you find my project interesting
and linkit to your page. Visit my Webcast to see Jabaco in
Community: http://www.jabaco.org/board/index.php Contact me for any
questions ... Best wishs from germanyManuel'==================
From: "Bill McCarthy" TPASoft.com Are Identity on 14 Jan 2009 22:12
"Ken Halter" <Ken_Halter(a)Use_Sparingly_Hotmail.com> wrote in message
> "Bee" <Bee(a)discussions.microsoft.com> wrote in message
>> Thanks all for a lot to chew on.
> Here's another wad of chaw to relieve some of your cravings.
> I just got this in the email yesterday. No time to check it out right
> now... too busy looking for a damn job!
As a job seeker how is the market for VB6 jobs looking ? From just a
cursory look at job sites like monster.com, it seems all the VB6 jobs want
..NET skills. Is that what you are finding ?
> ... funny.. if you take a look at the stock market (overall), VB Classic's
> demise (as far as MS is concerned) may be responsible for the shape of the
> global economy as we know it (stretching things a bit, eh? <g>)
LOL, next you'll be blaming Obama for the loss of your old job ;)
BTW: I think you need to look at some real figures:
Note MSFT dropped in 2000, and has remained pretty much flat since.
Absolutely no correlation to the NASDAQ or DOW etc.
> '==================Hello, since weeks ago I released a new project called
> 'Jabaco'. The target ofthis project is offering a BASIC programming
> language for the Java VirtualMachine with a VB6-similar syntax.
Interesting, but really if you want to program against the java framework,
best to use Java. That way samples, tools etc will all be relevant. And
there's lots of good tools out there for Java, and plenty of jobs for Java