snarfblam

Realistically, even if you throw a moderate amount of exceptions the impact on performance will be minimal. It is generally described along the terms of "Exception handling will only have a significant impact when exceptions are actually thrown." But "significant" is a subjective and relative thing. The first exception may take a half a second or so (probably less, it tends to be significantly less in version 2.0 than in version 1.x), and after that you need to throw a lot of exceptions before you begin to notice any degradation in performance. Besides, as has been said, if you are using exceptions correctly then when an exception is thrown, performance should be the last concern. And there is no other way to do everything that exceptions do (IIRC, On Error uses exceptions behind the scenes).

That shouldn't be too difficult or monumental. The real work is in laying out the logic. If you manage to do it, maybe it could be something to stick in the Code Libarary. First of all, you can break things up into triplets of numbers. The millions/ten millions/hundred millions places have absolutely no bearing on the thousands/ten thousands/hundred thousands places, which, in turn, have no effect on the ones/tens/hundres places. The hardest part would be the ones/tens/hundreds. Once you work that out, you can use the same exact method for the thousands, and just tag on the word "thousand" (the same goes for millions). Hundreds should be pretty easy. Just a number followed by "hundred." In fact, the only hard part, really, is the last two digits where you have to deal with the whatevery-ty and whatever-teen. I would keep a list of 10 numbers ("zero", "one", "two", etc.), a list of 10 "teens" ("ten", "eleven", "twelve", "thirteen"...), and a list of 10 whateverties where the first two (for numbers 0 thru 19) would be ignored ("blah", "blah", "twenty", "thirty", "fourty"...).

To answer the original question here, select "Show all files" under the "Project" menu to show the hidden designer files.

Doesn't look like it can be removed. To clarify, this is the equivalent of the "Properties" node in the C# solution explorer. Unlike the C# "Properties," and characteristic of VB8, the files that ultimately compose "My Project" are hidden in the solution explorer and only editable through the designer. To rectify this and view the components of "My Project" click "Show All Files" under the project menu. "My Project" must be there because it represents files that are part of the solution. (I would expect it to dissappear if all said files were to be deleted, but it doesn't). It doesn't take up extra space, however, since it replaces (and includes) AssemblyInfo.vb, and additionally includes the new Settings.settings, Application.MyApp, Application.MyApp.designer, and Resources.Resx files.

Not the article I remember, but a very good, clear article on multi-threading.

Could this be an issue with caching or volatility?

Wouldn't we be dealing with pointers or handles in C++ (depending on the version)? I'd think it would be something more like this: // 7 Control* c = (Control*) sender; System::String* text = c->Text; //or System::String* text = ((Control*)sender)->Text; // 8 Control^ c = (Control^) sender; System::String^ text = c->Text; //or System::String^ text = ((Control^)sender)->Text;

Sounds like some kind of race condition or threading issue. With that code you provided, I don't think that can possibly happen. Simply put, a computer couldn't run if it were that unreliable. It can happen as a result of logic error, or poorly coordinated multithreading (which is also, ultimately, a logic error). If these were class-level variables we were working with, it is very possible to have a very hard to find bug that can result in this kind of behavior. When dealing with pass-by-reference parameters this sort of thing can happen very easily. But I've never seen any actual instance of something so simple malfunctioning in such a manner (in other words, I've never seen a computer execute in a manner that blatantly defies the logic of the code). I've seen a similar article but it is only a vague memory and I can't recall the circumstances under which this kind of behavior was observed.

I tried to save with a hidden rich text box and it worked fine. But try this workaround: open a filestream and write the string returned by RichTextBox.Rtf. The result should be the same.

The two (Tutor's Corner and Code Samples) are only a few pages of threads each, but already it is difficult to find a particular tutorial/sample, and that's if you know what you are looking for. The lack of organization can (and has) lead to people posting questions that are already answered and makes it hard for the topics to serve their purpose. Some kind of catalog would be really, really nice. If possible. I know that vBulletin isn't really made for that kind of thing.

A few people have asked about bitmap manipulation recently. The biggest problem with GDI+ is that it can be pretty slow, especially on color-based per-pixel operations, since the only easy means of doing this is with the GetPixel/SetPixel function pair, which is slow This tutorial explains how to lock bitmaps and more directly access the data to give your app a huge performance boost. Code examples and samples are given in C#, but a language-neutral approach was taken (no pointers) so that the code can easily be converted to VB or C++ and is verifiable by the runtime. http://ilab.ahemm.org/tutBitmap.html Comments are welcome, here or by e-mail. Enjoy. Or don't. Whatever.

In your class, call base.Controls (or MyBase.Controls in VB). If you are hiding (shadowing) the base member, a coder can still get at it though, using the method I showed above.

I second that, mskeel. Interesting point indeed. It is unfortunate that Microsoft felt the need to completely hide the accessors from you without providing some kind of complementary feature to provide a delegate-like operation with a property. How about something like: delegate get int myGetAccessor(); void stuff() { myGetAccessor g = (get)this.SomeIntProperty; } Delegate Property Get MyGetAccessor() As Integer Sub Stuff() Dim g As MyGetAccessor = AddressOf Me.SomeIntProperty End Sub

You can maximize it and set the borderstyle to None, with no control box. It won't stop the user 100%, but its a start.

Which fill functions? There is no floodfill. As far as how to change palette entries, yes it has to be indexed. That means you need software that can save indexed bitmaps. If you have Photoshop, take the final image, go to the Image/Mode menu and select Indexed. It provides some options for automatic palette creation. After you do this, save it as a Bitmap (or GIF or any paletted format, GIF will support transparency). Go to Image/Mode/Color Table and you can view the palette. Look for the color you want to change. The hex code for that colors index is the y coordinate then the x coordinate (fifth row down and third column over would be 0x42). The code to modify a palette is as follows: ColorPalette palette = IMAGE.Palette; Color[] entries = palette.Entries; // Edit entries here // i.e. entries[0] = Colors.Pink; IMAGE.Palette = palette; // Palette must be assigned back for changes to take effect

I see no reason why this should not work. I'm not trying to call you stupid, but you have refreshed regedit after you ran the code, right? No exceptions being thrown? You have the necessary permissions? And your positive that the form is being disposed (destructed)? Have you tried verifying the results in code (re-read the registry key, show result in messagebox or w/e)?

What is that? Diesel, you can't return a control collection from a property of type string. Besides, the UserControl.Controls property is already read-only. The problem is that a coder can obtain the ControlCollection and modify that object, regardless of whether or not it is retrieved from a read-only property. Even if we did this: public new ControlCollection Controls{ get { throw new Exception("Can't touch this!"); } } A coder can do this: ((UserControl)WhatEverYouAreTryingToProtect).Controls.Clear(); And there is nothing you can do to stop him because that is just the way that a UserControl works.

As to whether it is more efficient to maintain a list of tiles to update or an array of bools that flags each tile, that depends on your situation. If you will only be changing a small percantage of tiles each update, it would probably be better to go with the arraylist because using the array of bools would require checking every tile for each update, where as with the ArrayList, you don't need to check tiles because you already have a list. If you will be changing most of the tiles, a bool array would probably be faster and more memory efficient, but unless this application is particularly grand it shouldn't really make much of a difference either way so you should do whatever makes your program easier to write. As far as tracking changes, this is what I would do: encapsulate the array in a class. Use an indexer or a function pair to access the array elements and have the class track the changes itself. I hate to throw another screen of code at you, but here is a pretty thorough example: // Warning: this class indexes different data than the data it enumerates. // Some people might frown on this. public class LevelMap: IEnumerable<Point> { int[,] data; // Map data List<Point> dirtyTiles = new List<Point>(); // List of changed tiles // Constructor public LevelMap(int width, int height) { data = new int[width, height]; } // This code allows a user to access the data and automatically // updates the dirty tile list public int GetTile(int x, int y) { return data[x, y]; } public void SetTile(int x, int y, int value) { data[x, y] = value; dirtyTiles.Add(new Point(x, y)); } // This code also allows a user to access data and maintains the // dirty tile list, but this property allows the user to access the // class using array-like code. public int this[int x, int y] { get { return data[x, y]; } set { data[x, y] = value; dirtyTiles.Add(new Point(x, y)); } } // This code allows a user to use a foreach loop to get dirty tiles public IEnumerator<Point> GetEnumerator() { return dirtyTiles.GetEnumerator(); } System.Collections.IEnumerator System.Collections.IEnumerable.GetEnumerator() { return dirtyTiles.GetEnumerator(); } // This code clears the dirty tile list after you have updated the screen public void ClearDirtyTiles() { dirtyTiles.Clear(); } } // Demonstrates the LevelMap class class Demo { public Demo(){ LevelMap myMap = new LevelMap(10, 10); // Setting data myMap.SetTile(5, 5, 10); myMap[4, 4] = 20; // Getting data MessageBox.Show(myMap[5, 5].ToString()); MessageBox.Show(myMap.GetTile(4, 4).ToString()); // Enumerate dirty tiles foreach(Point dirtyTile in myMap) { MessageBox.Show(dirtyTile.ToString()); } // Feel free to clear the list and start over. myMap.ClearDirtyTiles(); } }

GetPixel/SetPixel can be bad news. They are VERY slow. There are some other not so easy solutions. The first is to use paletted bitmaps, which actually allows you to go ahead and edit the palette. In other words, you can say "make everything that's blue change to green" by modifying a single palette entry, and it will happen like magic. That's assuming you have software that supports creating and editing paletted bitmaps. Photoshop can do this. The problem is that GDI+ renders paletted bitmaps somewhat slowly (but still a speed boost over changing colors with GetPixel/SetPixel), so if speed is critical, the only viable solution here would be to write your own blitting code (I've done it, and it's a pain). The advantage to paletted bitmaps is that you can have multiple palette entries that are the same color (you can have a guy with a red hat and a red shirt, and by using different palette entries you can change the color of the hat without changing the color of the shirt). Another solution would be to lock the bitmap and use pointers or Marshal functions to get at the data, and write your own color-changing code similar to the code you would write with GetPixel/SetPixel. (I will be posting a tutorial on this topic in the "Tutor's Corner" forum today or tomorrow.) Also, realize that if you are making a very simple game where you won't be doing too much palette style operations, GetPixel/SetPixel may be a viable solution.

Because your control inherits UserControl, it inherits all the behavior and properties of UserControl, whether you like it or not, with the exception of virtual functions and properties, whose behavior can be modified (and which the Controls property isn't). You can hide the controls collection by declaring a property with the same name and same signature and using the "new" modifier, but a coder can always cast your control to a UserControl and access the real, modifiable control collection.

-> is actually a shortcut. It is two operators in one: first it dereferences a pointer, then performs a member access. I would rather type var->member than (*var).member. It becomes necessary in C++ because C++ makes a bigger distiction between the concept of a reference and an object. (This actually became a big topic of discussion a while ago. Should == compare for value equality or reference equality? In C# it can go either way, but in C++ it is clear cut: var == var2 compares pointers and *var == *var2 compares values.) Besides, if you don't like the -> operator, you don't have to use pointers. You can actually write code like this: // No need for ->... MyClass myVar; myVar.Function(); // ...unless you want to use pointers and save some typing. MyClass * pMyVar; (*pMyVar).Function(); //I'm not positive that the parentheses are required pMyVar->Function();

Using static (or Shared in VB) you can not only create instance-independent functions but also properties, fields, and even events which are tied to the type itself rather than an instance of the type, which makes for some interesting possibilities, such as static event which is raised each time an object is created or destroyed. You can also tag a class with a static modifier that will disallow instantiation and the creation and use of instance members. Just don't get too carried away and forget they C# is primarily an object-oriented language. // We can't instantiate this class. // It is essentially a placeholder for functions, // fields, and properties. static class UserPrefs{ Rectangle windowLocation; // compile error (instance member) static bool LoadOnStartup; static string UserName; static void SaveSettings(){ } static void LoadSettings(){ } }

If you check the type before hand, DirectCast should always succeed. But just a note, the performance gain of CType is very minimal in most circumstances. You would have to do alot of casting to see any speed boost. As a general practice, though, I do avoid CType because there is a little appearent ambiguity to it. When compiled, CType will be converted to another cast that you can perform on your own anyways. It could be a DirectCast, a conversion between numeric types (CInt, CLong, CDbl), to/from a string (ToString, type.Parse). I think it's just nice to be explicit.

I was going to look at the home page and see what it was all about until it threw a few popups at me and one of 'em tried to force a download on me.

Not that you can't look this up in MSDN, but CType will perform a conversion if one is found, where as DirectCast will only perform a cast if the object being casted is an appropriate type. (i.e. an int can be CTyped to a string, but not DirectCasted. A Form can be DirectCasted to a control.)