Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Ron Garrett

Ron Garrett Regnwald Regnwald

Niner since 2009

VB6/VB.NET
  • Luca Bolognese: C# and VB.NET Co-Evolution - The Twain Shall Meet

    Lisa et al.

     

    I was surprised when MS introduced VBA rather than expand VB to include good Office support. That would have been MUCH better. Now MS can hardly dump VBA type of support for Office. VB of sorts has its biggest alliance there. It may be the cause of VB having been poorly supported in the move to .NET. VBA programmers may like the .NET environment more than I do. I HATE IT!! Its fine for development of applications that spend most of their time awaiting user input - "Northwind" sorts of applications. In that sort of application the user uses up the time wasted in unwrapping APIs and excessive type checking, by simply pondering the next move. But applications that work harder and longer between user inputs will suffer seriously. Pointers alone can greatly speed progress through large corporate or technical data structures. I'm not talking about $20 payroll and employee records. Large applications doing a lot of work would surely be advised to avoid .NET like the plague.

     

    Now that the .NET cancer is incurable I hope that VBA will be brought into VB (not the other way round). But there does need to be simple ways AROUND the .NET foggy marshland - a treacly morass it is. The talk of safe and unsafe code is foolish. Managed code has a safe (or do I mean unsafe) place to safely use pointers free of GC pilfering - where it places large (80Mb) objects or much-used objects (GLOBAL or STATIC) and I can see no reason why VB should not use this space for pointer arithmetic. The only problen that really needs attention is the provision of good, clean, direct, unencumbered access to addresses of data blocks (arrays, lists, collections, images, bitmaps) to READ AND WRITE! And unencumbered access to the APIs. It seems quite ironic (or do I mean ridiculous) that coding skills improved as one started to use Windows APIs directly in VB only to find that the deveopment of the language is measured by the degree to which we can no longer easily and directly get at them. Object-oriented programming is powerful - Class-oriented programming is often slow and tedious, never quite giving you what you really need.

     

    .NET tries to help the (novice?) programmer from making type and catastophic mistakes. Perhaps it succeds. But in doing so it also seriously impedes the (competent! and confident!) programmer from making significant coding progress.

     

    Since you invented the .NET quagmire you are the best to write a new best-seller entitled "Paths To Get Around In VB.NET" but with the "In" heavily crossed out!

     

    Otherwise, regards,

    Ron

     

  • What is Microsoft's Visual Basic 6 Support Strategy?

    Thanks, Androidi,

    I'll bear the card matter in mind when I upgrade, but I cannot impose that on my clients. My * with MS is that they did not maintain backward compatibility and that has NOTHING to do with .NET issues. It seems to be too much waste paper wrappers causing a mess in which the real contents get lost.

    I'll take on the accellerators though.

    Regards

    Ron

  • What is Microsoft's Visual Basic 6 Support Strategy?

    Paul,

     

    That post got badly chopped in the posting. Don't know why. Try again!

     

    G'day Paul.

    Well, you did ask what I want to do!

     

    I have a REAL LARGE BITMAP defined GLOBAL in VB -- the image -- BM1 (20 Mp; ie 80Mb as ARGB). The BM1.pvBits is to be obtained and transferred to a C/C++ routine. In C/C++ two SAFEARRAY structures SA1 and SA2 are defined with GLOBAL scope. SA1 matches BM1 as a 1D array. SA2 matches BM1 as a 2D array. The SAFEARRAY structures pvData are both pointed to the BM1.pvBits data. Two small arrays of bytes are defined GLOBAL -- Pic1() and Pic2(). Pointers to addresses of Pic1() Pic2() SA1 and SA2 are obtained. The SA1 pointer is copied into the Pic1() pointer and the SA2 pointer is copied into the Pic2() pointer.

     

    C/C++ returns nothing -- the job is done in situ.

    On return to VB the following should be true:

    The Pic1 no longer points to its small array, but to the BM1 data

    The BM1 data is now accessed by Pic1() as a 1D array

    The Pic2 no longer points to its small array, but to the BM1 data

    The BM1 data is now accessed by Pic2() as a 2D array

    Assembler accesses the BM1.pvBits

    The SAFEARRAYs never go out of scope, are immune to GC so BM1 Pic1() and Pic2() are safe

     

    WORRIES and DOUBTS:

    What happens to the Pic1() and Pic2() data references to data?

    Iits out of reach of the GC but small -- or should they be empty

    Does VB.NET give me BM1.pvBits -- VB 5.0 does ALL of this for me. GIVE ME IT BACK

    Is the SAFEARRAY structure still describing arrays in VB.NET

    What pointer type problems do I have in C/C++?

    Which C/C++ dialect should I use -- what headers.

    How does .NET deal with pointers to foreign objects in GLOBAL (unmanaged) memory

    How does native C deal with .NET

    C++ .NET will not build 2D arrays in GLOBAL scope -- in this case does it know it has?

    C++ .NET it seems, does not redefine global arrays and only defines them outside routines?

    This will have to be done for each image as the BM1.pvBits will occupy different memory -- I KNOW, CLEAN UP NEEDED!!

     

    That's a lot to lear for someone who has't needed to use C for nearly 20 years. But seriously, there is ONLY ONE WAY to get VB6ers onto VB.NET. You must be able to say TRUTHFULLY -- "VB.NET WILL DO EVERYTHING THAT VB6 DOES - AND MORE." But even then you have a clumsy technology which I suspect many C/C++ guys won't use. I would be happy to just stay with VB 5.0 were it not that a camera manufacturer's SDK requires VB.NET.

     

    Until you can say that you are largely wasting your time. Trust requires a proven track record of backward compatibility. A workaround is a pain at best and it means YOU FAILED. You ARE behind schedule with this and the VS bottom line suffers accordingly! But hope is eternal. What did Luca PROMISE me. If he does that, and catches up with the past, you may well get me caught in 2013.

     

    Regards, Ron

  • What is Microsoft's Visual Basic 6 Support Strategy?

    G'day Paul.

    Well, you did ask what I want to do!

     

    I have a REAL LARGE BITMAP defined GLOBAL in VB -- the image -- BM1 (20 Mp; ie 80Mb as ARGB).

    C/C++ returns nothing -- the job is done in situ. On return to VB the following should be true:

    The BM1.pvBits is to be obtained and transferred to a C/C++ routine. In C/C++ two SAFEARRAY structures SA1 and SA2 are defined with GLOBAL scope. SA1 matches BM1 as a 1D array. SA2 matches BM1 as a 2D array. The SAFEARRAY structures pvData are both pointed to the BM1.pvBits data. Two small arrays of bytes are defined GLOBAL -- Pic1() and Pic2(). Pointers to addresses of Pic1() Pic2() SA1 and SA2 are obtained. The SA1 pointer is copied into the Pic1() pointer and the SA2 pointer is copied into the Pic2() pointer.

     

    The Pic1 no longer points to its small array, but to the BM1 data

     

     

     Assembler accesses the BM1.pvBits

    The BM1 data is now accessed by Pic1() as a 1D array The Pic2 no longer points to its small array, but to the BM1 data The BM1 data is now accessed by Pic2() as a 2D array

     

     The SAFEARRAYs never go out of scope and are immune to GC so BM1 Pic1() and Pic2() are safe

     

            

     

     I would be happy to stay with VB 5.0 were it not that the camera control SDK needs VB.NET  Is the SAFEARRAY structure still describing arrays in VB.NET What pointer type problems do I have in C/C++? Which C/C++ dialect should I use -- what headers. How does .NET deal with pointers to foreign objects in GLOBAL (unmanaged) memory How does native C deal with .NET  C++ .NET will not build 2D arrays in GLOBAL scope -- in this case does it know it has?

     

    A fair number of issues for someone who hasn't needed to use C for nearly 20 years! I have a lot to learn.

     

    But seriously, there is ONLY ONE WAY to get VB6ers onto VB.NET. You must be able to say TRUTHFULLY -- "VB.NET WILL DO EVERYTHING THAT VB6 DOES - AND MORE." But even then you have a clumsy technology which I suspect many C/C++ guys don't use.

     

    Until you can say that,, you are largely wasting your time. Trust requires a proven track record of backward compatibility. A workaround is a pain at best and it means YOU FAILED. You ARE behind schedule with this and the VS bottom line suffers accordingly! But what did Luca PROMISE me?

     

    Regards, Ron

     

     

     

     

     

     C++ .NET it seems, does not redefine global arrays and only defines them outside of routines?

    What happens to the Pic1() and Pic2() data references to data? -- its out of reach of the GC but small -- or should they be defined empty Does VB.NET give me BM1.pvBits -- VB 5.0 does ALL of this for me. GIVE ME IT ALL BACK.

    This will have to be done for each image as the BM1.pvBits will occupy different memory -- I KNOW, CLEAN UP NEEDED!!!

     

    WORRIES and DOUBTS:

  • What is Microsoft's Visual Basic 6 Support Strategy?

    Paul, You made a gallant plea for migrants, but did you sell? I doubt it. You have the same battle as MS has with XP and Vista. Doubts.

     

    How can you possibly encourage me to drop VB5.0 and migrate to VB.NET when VB.NET cannot do - I repeat CANNOT DO - what I can easily do on VB5. Why should I be so foolish as spend $1000 or more for VS2010 if it DOES NOT DO THE JOBS I need to do, and can do now.

     

    For example, my most-used VB5.0 program processes astronomical images up to 80Mb in size, reducing image noise and reducing tonal range in stacked images, as well as doing metric and statistical work on the images. To achieve that, I use pointers to read bitmap data as both one and two dimensional arrays. I will NOT use lockbits for this purpose - at 72 yoa I cannot afford to wait for several GB of pixels to be moved back and forth between managed and unmanaged memory. And having left get and put long ago I have no desire to type those again. Dot NET may have advantages but it takes TIME coding,TIME compiling and ?TIME running. In addition, I call assembler routines which obviously use memory locations. VB.NET and C# cannot cope.

     

    If you ARE really desperate to get VB6 (and us real sceptics of VB5 and earlier) over to VB.NET you MUST maintain the coding tools of VB6. All your pleas MUST fall on deaf ears otherwise. You must see that. How cam interop rework code, that uses memory moves, to a platform that does not recognise them.

     

    I don't want the dog's dinner of pointer rubbish that litters C and C++. I am in the desperate situation of going ther. I hate it so far. I know plenty of C and C++ programmers who don't want it either! Just give me back:

     

    1)    VARPTR on any damn thing I want. Don't worry about the GC - you can restrict to proc to GLOBAL or STATIC which are outside its range. But give them back to me.

     

    2)   Clean methods to put them wherever I want to - pointers to array structures and data, bitmaps and bitmap data, and any user defined data structure.

     

    And please don't tell me its too hard. DotNET is doing it ALL THE TIME. Then you may be in time to sell me VS2013!

     

    But thanks for at least keeping the tenor of VB alive. As I said somewhere else, VB is a natural language worth far more than its image in some communities. I now spend a lot of time talking to my computer (Dragon Naturally Speaking). I don't let it talk back. It might win!! But even computer programming could move that way. Then I hope the conversation would be like that between Dillon and Andromeda than between the ?Arkona guru and his computer.

     

    On a related matter, what in hell is MS doing pushing yet another new general purpose language. We have enough. Its getting bad enough with image formats. Absorb the F# team and make VB more powerful that it was before .NET (and, OK, even C# can benefit too, though heaven knows why).

     

    Email me direct if you need to

     

    Regards

     

    Ron