Object's Virtual Frame

As an answer to the "un-escapable loop" problem I had a few days back, Object Oriented concepts are directly relevant. The virtual space an object take can be a complex topic and I will try to explain as I can.

Objects are just representation of a concept, or a class in VB. When creating a new object, you use the keyword "New" to tell the compiler that this object is totally another thing. When you have a clsChair class, you ideally want to pump out a chair that is going to be distinguished by other with its properties, its name, tag or any other. When VB sees the "New" keyword, its meaning to create another area in memory where this chair will be stored at. If you have two "New"' 's you will have two areas in your memory allocated to chairs.

Similarly, you can omit the "New" keyword entirely. And it will not give you an error. Because if you do not specify the "New", you will just use the class as default and only object. And note here, ONLY object. Meaning he will re-use the default one over and over.

I say defaut but its not exactly that way, an object is pointed to by its reference address. Say our class resides inside the memory at 0x11AA00, thats the "reference" I will be using. Lets say I want to get the number of legs our chair has, I tell my computer to look at whatever class is stored at 0x11AA0 and return me whatever leg property is in there. It will NOT use the name of the class you defined. And this is exactly the problem.

When using the technique I used, that is, not using a new. You end up with every object ( in this case, pictureboxes) using the same address. Same address means properties having the same values. When looping through my image matrix, the lowerbound and upperbound had the same reference address, therefore the first object is ALSO the last one. Which explains why it stopped after a single iteration. Because it already complete ALL its run in a SINGLE shot ( because every other tile were already affected instantly ).

Take a look at this picture:

I love the smell of burning CPU in the evening, smells almost like... Victory

Oh yes ladies and gentlemen. I have now a playable version of my game, its not much. But it is the content of all I've been doing these past 2 weeks. You can browse the code here and download an executable from this page.

And I DID solve my Un-Escapable loop problem, I'm going to make a port on this one. 


Milestone 2


After hitting more walls in my previous version of the program I decided to create another form where I would put only the code I need. To make it cleaner and more manageable. It is currently at its third iteration. But while I was looking at my code ( which was muuuch easier to read in a clean environment not chuck full of properties and classes anywhere) I though of the following logistic: I have two matrices, two arrays and 3 methods to help me put those on the form. If I followed my plan to make another matrix for the game hero, I'd have even more. So why not make it only 2 methods, one to fill the matrices, and one to show them. Simple since they do pretty much the same. And to that conclustion I said, why not have a single matrix ? Why would I need 2 layers when I could easily do it with one, and actually make this a lot more simpler and easy. The final result is that I have a single matrix of pictureboxes and two arrays with two methods to fill and stamp it. 

This is the code I used. you can see this all the simpler. 


The loop problem was caused by this: from the moment I decided to use an matrix of pictureboxes instead of images I changed from a type to an object. Do when typing 


Dim tileMatrix(15, 15) as Picturebox


What it did was to create 256 pictureboxes that are actually the SAME picturebox. Because there is no New()   I will create a subsequent post explaining this particular error but for now do understand that the problem was that every picturebox in my matrix was the same picturebox. It was a single one with 256 references through the matrix. 

A brief intermission.

I haven't been active a lot these days due to a couple things. First off I hit a problem on my project that is rather frustrating and I chose to take a break to get my mind off. I don't particularly mind problems when they're solvable. Like, the problem I had with the For Each that I will explain here is that kind of problem. Its possible to solve them using logic and a couple of tests. But there are problems that require a little bit more patience and hacking to solve.


The problem I have is related to the debugging phase. You get a bug, you yell "WTF !" you look in your code: nothing. You check the logic of your reasoning, the way data is handled: nothing. Then you decide to put a break point somewhere and run your program. Execution stops, you take a peek at the data, you see what the problem. you go back the code, you change a line or two and TADAM. Magic, problem solved ! But I did that, and nothing at all. Heres a sample of the broken code ( I thought I had it saved somewhere but it seems that part of code was deleted, here is something that should look like it. )

Sub something()
For Each c as heroTile in Me.Controls
       Me.controls.remove(c)
Next   ' Breakpoint right at this line. 


msgbox("Test Test Test")


End Sub
I inserted a break point at the Next keyword. And the msgbox method is for testing purposes, you will see why in a moment. After execution, the loops go through the controls and removes them. ( This will actually return an error, but this is just a sample to illustrate my problem ) When he hits the next, after every iterations are finished or while he is doing it. Execution stops. You heard me right, it just stops !! It will not budge, I can't make the execution go forward because he will NOT go to the next line. The compiler just waits there and looks stupid. I repeat, msgbox is NOT shown because execution will NOT go through that line. Which admittedly is weird. It might be something I'm missing or knowledge I don't have, but without a couple of hours of research I just can't see how I will solve this. Meanwhile, I thought of something for you guys:

For Next "Remove control" error.
Lets say I have this piece of code in a procedure:

Your guess is a good as mine, is scrolls through every control inside the form, and removes every pictureboxes. One by one, pictureboxes will be removed. From the first to the last. Unfortunately, you will find yourself with this result:

Can you spot why ? I'll tell you why. Because the Remove() function works in a special way. I made up a little .png to explain how it works. Image looks like crap but at least I can explain what it all means.

First lets say I have 10 picture boxes numbered 0 to 9. I want them all dead. I invoke the Remove() function inside a loop and I'm done. Actually, its otherwise. First, during the very first iteration of the loop ( lets say a For Each ) he will "plug" himself on the first picturebox he sees. He will then delete the control. BUT he will take every other control in the collection and move them one place up the collection. So element 1 will be element 0, element 2 will be element 1 etc. But a For Each works in ONE way and its numerically from the first control to the last. After deleting what was contained in the first address, he will move to the second EVEN IF THE CONTENTS OF THE FIRST ADDRESS WAS FILLED UP. At the second pass, he will remove the second element ( which is originally element #3, the second one is replacing the #1). This will create the blanks you can see in my output. Each one he removes, the next one is skipped. The problem is easily resolved by using a Do Until or another mechanism to check if there is a pictureBox remaining and delete it until there is none on the form.      

I'm hoping this piece will help some people when they see the same problem. This information was found using MSDN, never forget to hit the f1 key when you need help !