WFS Update

Hello Aaron,
Compiling this 2.3 edition with RB2006r2a2 gives these two errors:
1:
Code TreeViewTestWindow.Action, line 00003 Type mismatch error. Expected Picture, but got Int32.
2:
Code TreeViewTestWindow.Open, line 00009 Type mismatch error. Expected Picture, but got Int32.
I don't know what is wrong, maybe you could have a look at it?

So this is what you decided to do, instead of drinking.

Ah well, you have put your childhood behind you, I guess.

@Andre -- Yeah, I'm aware of that error, but it *is* an alpha, after all.

@Bill -- I watched two movies as well, so I did have SOME fun.

What, you didn't have the intestinal fortitude to watch the last LOTR movie?

Pffft. Read a book, geek.

Just wondering if the webcam code I adapted(and linked you to a while back) made it into the WFS. Hoping to see my name on that contributor's list. :P I've got some more stuff to send to you, too...if I ever get around to it. A few snippets from my latest program, AppStriker.

Sorry, but it didn't make it in this time (it's on the list of things to add still though). I basically took what I had working from the last while and packaged it up so that people using 2006r1 can compile the project again.

What is new about the Array keyword? I think I missed that day in class. =)

This code won't compile:

dim arr(-1) as Integer = Array( &h1, &h2 )

That's because &h1 and &h2 are both UInt's, but you're assigning to a signed int. The fix is to either use UInt32 instead of Integer, or use a signed integer in the array (use 1 instead of &h1, for instance).

Ah, right.

I forgot about the new datatypes and how the Array function is inflexible regarding type-casting. Although I wish the integer literals would typecast to Integer/Int32... that makes using Enumerations more painful than they could be.

Arrays in general are more painful than they could be.

dim arr1() as double = array( 1, 2, 3 ) // fails because 1, 2, and 3 are integers
dim arr2() as uint8 = array( 1, 2, 3 ) // fails because 1, 2, 3 are Int32's
dim arr3() as Window = array( Window1, window( 0 ) ) // expected Window() but got Variant() ??

dim arr4() as integer = array( 1, 2, 3 ) // works
subWhichTakesAnArrayOfSingles( arr4 ) // fails

My favorite is:
dim foo() as single = array( 1.0, 2.0, 3.0 ) // fails: expected single(), but got double()

Feature request time! :-)

@Asher
We had a long discussion on the array typing problems on the Betas list before 2006r1 came out. I had made suggestions how the compiler could deal with these (assuming that all the array's values are constants, meaning the compiler could build the constant and then change the values once it's assigning them all in one piece easily), but it appears that internal ways of the compiler do not currently allow this. So, not much sense in requesting this unless Mars gets to rework some of this stuff, I guess, which may be a bigger task... At least, that's how it sounded.

Well, only that this one of yours can't really be fixed:

dim arr4() as integer = array( 1, 2, 3 ) // works
subWhichTakesAnArrayOfSingles( arr4 ) // fails

Here, arr4 is not a constant, and that you then get a type incompatibility error is totally expected and normal. After all, arr4 is now explicitly typed. The stuff that could be fixed is where you use Array(...) and Array is not explicitly typed yet in the above example (1 is not always an integer, it could also be a int8 or even a double, depending on where you want to use it)

And Mars seemed to agree with this, only he did not be too eager to discuss this, meaning it's something that bugs him as well, apparently :)