snarfblam

Not quite sure what you meant by that. Do you mean operator/casting overloads? I can't really think of any scenario where a "correct assignment operator" can't be determined at compile time.

Anyone who has spent more than a little bit of time getting their hands dirty with reflection will be well aware that all kinds of magic can happen through the System.Type.InvokeMember method. Unfortunately, though, this function has a large number of parameters to cover nearly every member invocation/access scenario and it can become tedious stringing together confusing parameter arrays and binding flags and determining which parameters are relevant for every invocation, and the resulting code is very difficult to read. The Reflector class provides a number of methods that expose .Net's reflection capabilities in a more intuitive manner (and extends that functionality). Numerous overloads are provided for several clearly named functions that perform a specific type of reflection (method invocation, property getting, field setting, etc.). Additionally, the Reflector class uses a cut-down version of my Subscriber class to enable event handling through reflection. Consider the following approximately equivalent code listings: // Using standard reflection Type myType = this.GetType(); // Change form's text myType.InvokeMember("Text", System.Reflection.BindingFlags.FlattenHierarchy | System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.Public | System.Reflection.BindingFlags.SetProperty, null, this, new object[] { "Reflected!" }); // Change form's private dialogResult field myType.InvokeMember("dialogResult", System.Reflection.BindingFlags.FlattenHierarchy | System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic | System.Reflection.BindingFlags.SetField, null, this, new object[] { DialogResult.OK }); // Hide the form myType.InvokeMember("Hide", System.Reflection.BindingFlags.FlattenHierarchy | System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.Public | System.Reflection.BindingFlags.InvokeMethod, null, this, new object[0]); // Using Reflector Reflector Me = new Reflector(this); // Change form's text Me.SetProperty("Text", "Reflected!"); // Change form's private dialogResult field Me.PrivateAccess = true; Me.SetField("dialogResult", DialogResult.OK); // Hide the form Me.InvokeMethod("Hide", Me.NoArgs); Not all overloads of all methods have been tested thouroughly. Feel free to post questions, comments and bugs. reflector.zip

Well, what does that really say, mskeel? The confusion seems to be that something like someArray[someIndex] = someValue; is viewed as a two-part operation. You can think of it as calculate the value and store the value. You can also think of it as find the desination and then put the value there. Neither of the two is the case. I noticed that you used the term "visited," IceAzul. There is a difference between determining the destination and actually accessing ("visiting") it. There are three parts to this operation: evaluate the destination, evaluate the value, and perform the assignment. The third part is dependent upon the first two parts, but each of the first two parts is independent. There is no need for one to be evaluated before the other. In other words, yes, you need to know where you will put something before you can put it there, but you also need to what to put there before you can put it there. The order in which these things are done is (presumably) simply a matter of the order that they appear in the syntax. There is no other reason to do it any particular way. If you were to hand-write the MSIL you could do it in which ever order you like. The stelem (store element) MSIL opcode lends itself to evaluating the destination first, but with an extra opcode or two it can be done the other way. As to which way is more intuitive, it depends on what analogy you use to understand assignment within an array. If I had to guess without actually writing the code and executing or decompiling it and I hadn't looked at a decent amount decompiled code, I would probably expect that the value to be assigned would be calculated first, but I wouldn't count it as more than a guess.

Dotnet applications are JIT-compiled. Only the smallest portion of time is spent compiling code for a CPU-intensive and relatively simple operation like this. The code is running in good ol' X86 with very little interaction with the CLR from start to finish. One thing to take into consideration is that when your code is JIT-compiled it is optimized for the computer on which it is running. Also, certain bottle-necks that are often encountered in computing do not become an issue here. There is no disk/Internet/ or special hardware I/O going on here. There is no graphics rendering going on. So your work computer's poopy graphics card and slow hard drive and crappy network aren't going to slow you down one bit. In fact, with code this simple and so few variables you won't be dealing with many page faults and there will be very few CPU branch mis-predictions. In other words, all the things that speed your nift-o-tastic gaming PC up become irrelevant.

I don't see how that is counter-intuitive. When there is no other precedence the default precedence is left-to-right. Why should either the assignment target or the value be evaluated first? You need to calculate a pointer for the assignment and you need to calculate a value to be assigned, but at the actual point of the assignment it doesn't matter which was calculated first, as long as you have both. "=" is a binary operator, just like the addition operator, the member access operator, the multiplication operator, etc.. Even with the assignment operator, the left-hand value is always calculated first.

Actually, for the sake of experience and entertainment, I wrote a program that used my own algorithms to encrypt files with a key based on a password. After the fact I looked over some encryption algorithms on Wikipedia and was surprised to see how similar some of them were to mine (the biggest difference being that they used a larger encryption key). Anyways, events really boil down to multicast delegates under the hood, which, behaviorally, resemble an instance of List(Of Delegate). In other words, they are relatively predictable. Generally, the events will be fired in the order that they are attached. I say generally because this probably is not part of the .Net standard, meaning that other implementations (ex. Mono) and future versions of .Net do not guarantee the same behavior.

Under the Debug menu go to "Exceptions..." What exactly you see depends on what version of what language(s) you are using, but there should be a way to stop execution not only on all exceptions, but you can pick and choose which exceptions to break on.

Did you know that it is free code week? I don't quite understand your code, but I'm sure it works. Either way, I whipped up this example to show how this could be done in a more "standard .Net" way. You don't have to use it, of course, but it is food for thought. This code is pretty well commented, but here is the jist. I took the PictureBox class and added a new event that is similar to the MouseMove event. If the cursor is over an object then the handler should call the SetCrossHair method on the event args. Otherwise, don't. Simple. ' This class exposes an event that allows event handlers to set crosshairs. Public Class CursorPictureBox Inherits PictureBox ' This variable keeps track of whether the current cursor is a crosshair. Dim Crosshair As Boolean ' The event where the magic will happen. Public Event CheckCrosshair As EventHandler(Of CrossHairEventArgs) ' This is the important stuff: Protected Overrides Sub OnMouseMove(ByVal e As MouseEventArgs) ' We are supposed to call the base method to make sure MouseMove events are raised. ' This is not significant. MyBase.OnMouseMove(e) ' We create our new event args class. We initialize the CrossHair ' property to False. If any event handlers feel compelled to show a crosshair, ' they should call SetCrossHair, which will set the property to true. Dim EventArgs As New CrossHairEventArgs(e, False) ' Raise the event so that handlers can do their thing. RaiseEvent CheckCrosshair(Me, EventArgs) ' Now, if our new Crosshair value is different than the old one ' then change the cursor to the appropriate cursor. If EventArgs.CrossHair <> Crosshair Then If EventArgs.CrossHair Then Cursor = Cursors.Cross Else Cursor = Cursors.Arrow End If End If ' Store the new Crosshair value. Crosshair = EventArgs.CrossHair End Sub End Class ' This class extends the MouseEventArgs and allows a handler to specify that ' a crosshair should be used. Public Class CrossHairEventArgs Inherits MouseEventArgs Dim _CrossHair As Boolean Public ReadOnly Property CrossHair() As Boolean Get Return _CrossHair End Get End Property 'This is the method that handlers should call to indicate that a crosshair should be shown. Public Sub SetCrossHair() _CrossHair = True End Sub Public Sub New(ByVal e As MouseEventArgs, ByVal CrossHair As Boolean) MyBase.New(e.Button, e.Clicks, e.X, e.Y, e.Delta) _CrossHair = CrossHair End Sub End Class Here is the usage. I know that my code listing was much longer than yours, but the nifty part is how simple and intuitive the event handlers are. (I used a picture with a circle centered at 20, 20 with a radius of 20 and then used the following event handler to show a crosshair when the mouse is over the circle.) Private Sub MyBox_CheckCrosshair(ByVal sender As Object, ByVal e As CrossHairEventArgs) Handles MyBox.CheckCrosshair If ((e.X - 20) ^ 2 + (e.Y - 20) ^ 2 < 400) Then _ e.SetCrossHair() End Sub

Those are some pretty good suggestions. I would never have come up with the square root one. But I'm going to elaborate on #1 and throw another idea out there. When dealing with numbers higher than four, instead of incrementing by two each time, you could increment by four, then two, then four again, then two again, and so on. The reasoning is similar to that of mskeel's. You can count by two because every other number is not prime, being a multiple of two. If you take the same kind of consideration for multiples of three you will see that for every six sequential numbers, only two are potential candidates for prime numbers (the first and the fifth, if you start at 1). You could expand it even more for dealing with multiples of five but at that point you need to do a lot of copy-and-paste coding or use clever algorithms to determine how much to increment the counter by each time. My other suggestion would be to use Int32s instead of Int64s when dealing with numbers less than two billion. They perform much faster on a 32-bit computer.

You can not store dynamic data (i.e. data that can change) within an executable. Why are you opposed to using a file to store data? I use the registry sometimes, but there are people who would tell you not to. The reasons are (1) the registry is not portable between operating systems, though this is not a problem for most users/programmers, and (2) if the application is installed onto a disk, thumb drive, etc., the settings will not be stored alongside the application, which means that the user will have to configure the application for each computer he uses it on. The registry is more for setting/configuration data than other types of data, but if you do choose to use the registry, the registry classes are well documented on MSDN on the web (I know that the help files for Microsoft.Win32 classes are not installed on my local MSDN). I personally recommend a database or a file. It can be less than convinient to have more than one file to distribute/copy/move but that's usually the way it has to be.

A better solution to your problem could probably be given if we knew more about what exactly you are trying to achieve. Who needs to know that the event has been dispatched to all handlers? Are the classes in question something you've written, a .Net component, or a third party component? Events are for the very simple purpose of broadcasting information. What you want is slightly beyond the scope of a single simple event. If you are writing the class that is raising events you could consider doing something like a second event which is fired after the first (similar to some .Net events where you have OnFormClosing/OnFormClosed and BeforeLabelEdit/AfterLabelEdit). When the second event is fired you can safely assume that the first event is finished.

I didn't go to great lengths to optimize the code I wrote. If you are looking for raw speed you might want to write your own new function. Just because the function is written in VB doesn't mean that it will be slow. You can use a tool like .Net Reflector to examine the compiled code and do some benchmark tests to tweak the code. You could even write the code in MSIL if you want to get the most out of your CPU cycles.

Are you looking for some sort of graph control? You either have to find a third party component to do this or do it yourself. Visual Studio doesn't come with graphing classes/controls.

IndexOf will only find a match for a single byte. We aren't really supposed to give code handouts here because it tends to discourage thinking, but I was bored so I whipped this up. 'This function searches by using the Array.IndexOf method to find a match for the first 'item in the search array and then looping through the rest of the search array testing for a match. 'This is repeated until either a match is found or the end of the array is reached. Public Function SearchArray(Of T)(ByVal array As T(), ByVal search As T(), ByVal start As Integer) As Integer 'In the event of empty or null arrays return no match If array Is Nothing Or search Is Nothing Or array.Length = 0 Or search.Length = 0 Then _ Return -1 'Looping variables Dim index As Integer = start - 1 'Where we will begin searching Dim match As Boolean = False 'Will be set to true when a match is found While Not match 'Find the index where we have a match for the first item in the search array 'starting from 'start' or after our last match index = System.Array.IndexOf(Of T)(array, search(0), index + 1) 'A value of -1 means we have searched to the end of the array and found nothing If index = -1 Then _ Return -1 match = True 'Assume we have a match until we discover that we don't. 'Loop through the search array from the second item to the last For searchIndex As Integer = 1 To search.Length - 1 'If an item doesn't then abort the for loop and continue searching array for matches If Not (array(searchIndex + index).Equals(search(searchIndex))) Then match = False Exit For End If Next End While 'If this code has been reached we have found a match. Return the index. Return index End Function 'This overload provides a default index of 0 (we could also use an optional argument) Public Function SearchArray(Of T)(ByVal array As T(), ByVal search As T()) As Integer Return SearchArray(Of T)(array, search, 0) End Function Usage is as follows: 'Search char array "MONKEYS" for "KEY" Dim Data As Char() = {"M"c, "O"c, "N"c, "K"c, "E"c, "Y"c, "S"c} Dim Search As Char() = {"K"c, "E"c, "Y"c} MessageBox.Show( _ SearchArray(Of Char)(Data, Search).ToString() _ )

Unless you want to create functions that do this for you, you are, for the most part, out of luck. You could create a constructor for Class1 that accepts an instance of Class2 and copies all of the fields, allowing you to create a Class1 from a Class2, but that is about as good as it gets unless you want to get your hands dirty with reflection. Here is the problem: polymorphism. Suppose you have ClassA, which is used to copy a file, and ClassB, which inherits from ClassA to extend it and copy files from the internet. ClassA has two properties: Source and Target, which specify from where and to where the file is copied. ClassA also defines a virtual (overridable) function named PerformCopy which copies the file. ClassB simply overrides PerformCopy, adding logic that allows files to be copied from a URL in addition to a file path. Now you create an instance of ClassB whose Source is "ftp://ftp.mysite.com/somedoc.html". If you call PerformCopy the file will be copied from the Internet to the hard drive. However, if you force the object to an instance of ClassA all of a sudden it loses the capability to copy files from the Internet and your object is broken. Values that were valid are no longer valid. Besides that, in the grand scheme of object-oriented programming, that type of conversion doesn't make much sense. It is like wanting to be able to change your rice from regular rice to pork fried rice and back again. You can't do that. It is what it is. Reality doesn't work that way, and OOP mimics that aspect of reality. Sorry, but you are stuck with white rice. That being said, I wrote this function in VB that uses reflection to convert an object into an intance of a base class. The stipulation is that the base class must have a public default constructor and there is no guaruntee that there will be no broken objects as a result of lost polymorphism. Also, the code must be run in a full trust context. Public Function DownCast(Of T As New)(ByVal source As Object) As T 'A System.Type that represents the base type we are converting to 'which we can use for reflection. Dim targetType As Type = GetType(T) 'Throw an error if the source object does not derive from the target type. If Not source.GetType.IsSubclassOf(GetType(T)) Then Throw New ArgumentException("Source must be instance of a class derived from <T>.") End If 'This is the resulting object, which is an instance of the base class. Dim Result As New T 'Now we will loop through each field in the BASE CLASS and copy the value from 'the source object to the resulting object. '(We need full trust because we must copy private members, which can't be accessed in partial trust contexts.) For Each field As FieldInfo In targetType.GetFields(_ BindingFlags.Public Or BindingFlags.NonPublic Or BindingFlags.FlattenHierarchy Or BindingFlags.Instance) field.SetValue(Result, field.GetValue(source)) Next Return Result End Function Sub SillyExample() Dim Derived As New ArgumentException("message", "param name", New Exception()) Dim Base As Exception = DownCast(Of Exception)(Derived) MessageBox.Show(Base.Message + " " + Base.InnerException.ToString()) End Sub

Using option strict means that you need to think alot more in terms of types. Every reference (whether it is stored in a variable or the result of a function or expression) has a type, and every object has a type. eventSender is a reference and its type is object, so the compiler doesn't know anything about it except that it is an object (event though it is actually a RadioButton). DirectCast(eventSender, RadioButton) is actually an expression that converts the type of the reference, so we start with a reference to eventSender as an object and end up with a reference to eventSender as a RadioButton. You are doing more than telling the compiler that eventSender is a RadioButton. When the program is running the .Net runtime will actually verify that eventSender is indeed a RadioButton and then change the reference to eventSender from a reference to an object to a reference to a RadioButton. If eventSender isn't a RadioButton an error will occur when the DirectCast is executed. The VB feature that allows you to use methods on an object when you don't know the type, late binding, actually requires VB to determine the type of the object and search that type's functions for the function that has the same name and the closest match for parameter types before the function can be called, and that is done each time the function is called. In other words, late binding is slow on top of error-prone.

Just a question? Why are you killing the processes instead of simply closing them, i.e. SingleProcess.CloseMainWindow()

It is more than a matter of the scope of a project and no assumptions must be made. If you skin the cat with a skill saw you're going to have a nice mess to clean up and not much of a cat to speak of. Concatenating strings to make SQL statements is a bad idea because it is a very bad habit to get into. The first thing that someone who thinks they are a 1773 H4x0r will do is try to inject malicious code through input fields. And... it can be error prone. Regardless of the scope of the project. The simple reality is that it is just one of those things that you shouldn't do because one of these times it is really going to come back and bite you. Don't get me wrong. You can feel free to do it and you can dismiss our suggestions because just this once won't hurt or because we haven't reviewed your code. But it is something to keep in mind. We are only here to help, not to tell you what to do.

It will not cause a memory leak. The only way to cause a memory leak is to forget to release references to large numbers of objects. On a collection the GC will still see the allocated objects and see that they are or are not referenced. The problem is that certain tasks do not get completed where the code had inticipated that they would. For instance, objects won't dispose and certain variables might not be updated properly. If there is an object using unmanaged resources, such as memory or open files, those objects could end up going undisposed until they are collected by the garbage collector.

You can just check Form.InvokeRequired. It will return the same value that a StatusStrip would.

It appears that your link is invalid.

Don't ever think that I'm too proud to learn something from a less experienced programmer, but I'm a little confused. What is the advantage of the second listing of code you posted? And just for the record, I gave VB up about a year ago in favor of C# because I like the syntax more and because VB seems to be separating itself from the .Net mainstream (for instance, the large number of VB-specific functions and the "My" feature). I can carry almost anything over from C# to VB, but vbCrLf and My.FileSystem just don't translate into C# so easily. Oh, and please stop cheating on us. It hurts us inside.

Sorry, I guess I didn't read your original post very thouroughly. It is unfortunate if the code you are calling is beyond your control, but it is always a possibility, I suppose. You can try to immediately terminate the thread using the System.Threading.Thread class. If you want to do things a little more neatly the only other option I can come up with is to set the thread's priority to Lowest (if it isn't already), allow it to terminate on its own, and hope that it doesn't steal too many CPU cycles. If the thread is simply blocking it shouldn't be eating up the CPU cycles, but if the operation is CPU intensive then I guess you're just stuck between a rock and a hard place.

Simply put, you need to store a reference to the timer. It doesn't matter where. If there is a specific class that uses it then that class should keep a reference to it and as long as the class as referenced the timer is referenced. The fail-safe method would be to store the timer in a static variable, which will never be garbage collected until the application closes.

Never mind. BackgroundWorker.CancelAsync has no effect on the ThreadState property. I know that there is little documentation on BackgroundWorker on MSDN installed with VS, but I went online and searched MSDN and found that