Is there a way to work around the zero-base dimensioning in VB 2010

Question

1.00/5 (1 vote)

See more:

Hi,

I am trying to convert an app from VB 6 to VS 2010 and have an issue with the zero-based array dimensioning.

I use many arrays with indexes that are meaningful to the application, for example dim FiscalYears(1990 to 2013) as string.

Clearly there are dozens of ways to actually get this done using aliases or whatever but that entails huge changes to the programming logic and all the new bugs that introduces.

I have a vague memory or reading a discussing on this topic a few years ago and the author offered a way to actually dim () using whatever boundaries you wanted but I have no idea when or where I may have read it.

Does anyone have a workaround that doesn't involve huge rewrites?

Thanks.

Murray

Posted 10-Jul-13 12:03pm

dg6yhw11

Add a Solution

3 solutions

Solution 1

Well you could just ignore the first element (and adjust any counters etc accordingly).

There's a workaround[^] documented here - I'm not recommending any workaround however, experience has taught me that they cause more issues than they cure!

You might be thinking of the old Option Base statement - but that is obsolete in VB.NET.

If you really were doing things like FiscalYears(1990) etc then it's for sure your application didn't begin life in VB3 :-)

Any opportunity to use Consts or Enums for the indexes to get around this?

Posted 10-Jul-13 12:11pm

CHill60

Comments

dg6yhw11 10-Jul-13 19:11pm

Thanks for answering. Actually the app was born in TurboBasic in the early '90s and was ported to VB6 when DOS died. The old Option Base let you select the default lower bound but you could always use whatever you wanted.

I looked into using constants and enums but they're too clunky and rigid. The beautiful thing about using years is the program is self-updating - at least in those areas where I can just use the System Year.

The other issue is I always try to use LBound() and UBound() in loops to avoid those Error 9 situations.

It almost seems like MS doesn't want us to use arrays any more but I can't figure out just what they intend us to use instead. A lot of engineering and accounting math works really well using arrays.

Sergey Alexandrovich Kryukov 10-Jul-13 19:33pm

You probably missed something. System.Array actually does allow you to use not that zero-based indexing in a simple explicit way. Just look at the documentation. (Or my answer, Solution 2).
—SA

Solution 3

Another option is to skip the arrays altogether and go with a key/value pair collection like Dictionary(Of Integer, String).

This is an oportunity to rewrite and embrace new technologies that are far superior to what you've been using in VB6. I wouldn't waste the time trying to shoehorn VB.NET into doing it "the old fashioned way".

Posted 10-Jul-13 14:03pm

Dave Kreskowiak

Updated 10-Jul-13 14:06pm

v2

Comments

dg6yhw11 11-Jul-13 14:42pm

Thanks Dave.

As a professional with thousands of users who depend on our code, we cannot embrace every new technology for its own sake.

I don't know where you live but here we have an expression that states "if something is working, don't fix it".

Array manipulation has been a core of programming since programming began. It is an elegant and easy way to work with numbers. It is also very cpu-cycle-efficient. You can do a lot with very little code.

It seems to me that Microsoft has forgotten the importance of business programming in their panicked desire to capture the Twitter-centric generation.

This is one reason why VB 6 is still the preferred language of business.

Dave Kreskowiak 11-Jul-13 15:10pm

The whole "If it ain't broke dont fix it" doesn't hold true for VB6 code. I work for the largest insurer in Michigan. There are groups in here that hold on to VB6 following the very same idea that you just regurgitated. You could call me a bit of a .NET Evangelist here. To "convert the masses" here, I take examples of code that they wrote and re-write it in VB.NET/C#. The resulting code is usually very much shorter than what they wrote, more robust, easier to understand (and therefore support = reduced costs$$$) and, because the code is shorter, cuts down the number of bugs.

dg6yhw11 11-Jul-13 15:46pm

Sorry but I totally disagree.

It doesn't matter if that code was written in VB6, C, C#, F#, FORTRAN, COBOL or Swahili; If that code was working, not causing any problems and had no business need to be touched, then you just wasted your time and possibly introduced a bug that did not need to be there.

I am the first to admit that VS 2012 is way cooler than VB6. You can do lots of neat stuff with it. C# is swell. So is HTML5, XAML and all the rest. We can create really cool interfaces that users might actually be able to understand. We can connect to the Web very easily.

But it sucks for business. File I/O, Printing, and many other line-of-business requirements are just plain awful.

VB6 may work really well for the apps that your co-workers are responsible for, just as C# works really well for you. Perhaps you can cut them some slack.

Dave Kreskowiak 11-Jul-13 16:01pm

Well, there's no way I can agree with you, for two reasons:

1) The VB6 runtime is unsupported and evertually will not even run on Windows any more.

2) Just by converting your project to VB.NET, you're introducing new bugs, right now.

dg6yhw11 11-Jul-13 16:12pm

You're comment about the VB runtime is valid to a degree. Here's what Microsoft says:

"Microsoft will support your existing Visual Basic 6 components and applications through the lifetime of Windows 7 client and 2008 R2 server."

I didn't bother to look up the life of Win 7 (Of course, large companies will have to start adopting it sometime...:))

As for 2, I have a business need to send data using XML and SOAP. So I have to write something in VS 2012 to do that. Part of the fun involves trying to create VS Structure's that match the UDTs used in the VB 6 data files.. int is now int32, long is int, currency doesn't exist. What a PITA.

Needless to say the 245,780 or so lines of the main program are not going to be converted any time soon.

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2013-07-10T13:31:00

Of course arrays allow indexing which is not zero-based. You just had to read documentation more thoroughly:

[EDIT]

This method gives you the possibility to work with specified low bound which does not have to be zero:

http://msdn.microsoft.com/en-us/library/x836773a.aspx[^].

For example:

VB

Dim myArray As Integer() = System.Array.CreateInstance(
    GetType(Integer),
    New Integer() {10}, ' 1-dimensional, length of 10
    New Integer() {3}   ' starting from 3, not 0 
) ' similar with multidimensional arrays
  ' the two arrays above will have rank number of elements

[END EDIT]

For using these indices, you can use appropriate GetValue and SetValue methods. Please see: http://msdn.microsoft.com/en-us/library/system.array.aspx[^].

You should know that not a zero-based indexing is not standardized as CLR-compliant. However, if you always develop with C# and VB.NET (and actually other languages), you can leave with it.

That's all, easy enough.

—SA