snarfblam

An important point in the design of the DotNet framework is that memory leaks are very difficult to create. There are only two ways to create memory leaks that I know of. The first is to create objects and never release references to them (for instance, store them all in a List<T> object). The other is to use unmanaged code (ActiveX, P/Invoke, etc.) which already has a memory leak. Neither of these are generally a problem. One should still make considerations when it comes to memory management, however. References to large objects should be released as soon as possible, and IDisposable objects should be disposed as soon as possible. Even if you neglect to follow these guidelines, though, you generally have to go out of your way to create a real memory leak.

That is correct. The VB function is available mainly for backwards compatability reasons. They both basically do the same thing, but the syntax is different. Also, I'm not sure whether or not they work exactly the same. You would have to look at the documentation. Trim() works the way it did in VB6. String.Trim() works the DotNet way. There may be a difference in what they consider whitespace. They may be the same, they may not be. I don't know. [Color=Blue]Dim[/Color] spaced [Color=Blue]As String [/Color]= [Color=DarkRed]" spaced out "[/Color] [Color=Blue]Dim[/Color] unspaced1 [Color=Blue]As String [/Color]= Trim(spaced) [Color=Green]' results in "spaced out"[/Color] [Color=Blue]Dim[/Color] unspaced2 [Color=Blue]As String[/Color] = spaced.Trim() [Color=Green]' also results in "spaced out"[/Color]

Re: Debug vs Release It seems there is some confusion here between making a debug build and running in a debugger. When you run your code in the IDE you are running the code in a debugger. You can do this with a debug build and a release build (some features require a debug build, though). This really has nothing to do with DEBUG and RELEASE builds. If you select RELEASE and run the app from the IDE, you are debugging, but you are debugging a release build. The difference is when you select DEBUG or RELEASE from the build menu you are choosing a build configuration, or a preset set of compiler options, (which can actually be customized, and the use of the traditional "DEBUG" and "RELEASE" configurations isn't really necessary, it's just the way it is done). The default DEBUG configuration defines the DEBUG symbol (this means that code included in an #if DEBUG directive will be compiled), disables optimizations, and produces a debug database (which helps syncronize the debugger and the program, like MrPaul mentioned). The default RELEASE configuration does not define the DEBUG symbol (#if DEBUG code won't be compiled), optimizations are enabled, and no PDB (debug database) is generated.

I think that, in general, what is considered proper is to create helper methods on a form that perform whatever UI operations you need to do from a secondary thread. You can call the Invoke method on said form (which should have been created under the GUI thread) to execute the code on the main thread. This would include creating new forms. If you want to create a new form from a second thread, you should have that second thread invoke code on the main thread to do so. For instance, the app's main form can have a method to create a form and return a reference to it. The secondary thread invokes this method via the main form's Invoke method. Now suppose this secondary thread also needs to update the newly created form. The newly created form should expose methods that can be invoked from the secondary thread using the newly created form's Invoke method.

Windows provides another feature that provides this kind of functionality: a screen saver. If you specify a screen saver password and a reasonably short delay before the screen saver is shown then in order to use the computer a password would be required. You can even create a shortcut to the screen saver on your desktop (if you look in the System32 folder, they have the extension .scr) so you can run the screen saver without waiting.

The problem here is that we can't see what you are doing inside the loop. Generally, a For Each loop can be substituted for the loop you've written in the original post, but if you need the index of the item you are examining, a For Each won't cut it. Just to show the difference: [Color=Blue]Dim [/Color]SStr() [Color=Blue]as String [/Color]= {"Val1","Val2","Val3"} [Color=Blue]For [/Color]index [Color=Blue]As Integer [/Color]= 0 [Color=Blue]to[/Color] SStr.Length - 1 Console.WriteLine(index.ToString() & ": " & SStr(index)) [Color=Blue]Next [/Color] [/Code] results in: [Code] 0: Val1 1: Val2 2: Val3 [/Code]

Would the string.Trim function suit your purposes? [Color=Blue]Dim[/Color] Trimmed [Color=Blue]As String [/Color]= ([Color=DarkRed]" SPACES "[/Color]).Trim() [Color=Green]'Trimmed = "SPACES"[/Color] [/Code] [Edit]Looks like David Anton beat me to the punch, but now I'm not sure whether you were looking to trim both the start and end at once, or only one or the other. Now we have all our bases covered, I guess.[/Edit]

An alternative would be to go to microsoft.com and find the DotNet redistributable package and provide a link to that alongside your executable. Other DLLs should not be distributed unless the license allows it. (The proper thing to do in this case would be to instruct the user how to obtain his own copy of the DLL.) What I often do, since I usually distribute applications via the web, is distribute only the executable and other necessary files authored by me, and provide links to downloads for other components (unless they are small in size), avoiding large redistributables (especially the DotNet redistributable). But if you want it all in one package, Nate Bross has the right idea with the Deployment project (this is only available with Standard versions of Visual Studio or higher).

Having no idea what your code does, this is all I can tell you. Since the exception is thrown in Server.exe, there isn't necessarily anything wrong with your code. I'm not quite sure what the address 0x7c81eb33 refers to, but 99% of google search results associated that offset with kernel32.dll (not that that probably helps much). It also seems to be related to things like static initializers and Windows Forms initialization.

The shrug is missing, but the alternate text, [PLAIN]:-\[/PLAIN], is showing up in my browser (FireFox 2.0.0.2).

Center the controls within the panel in the designer (either manually or via the Format menu). Then, go to the property window, find the Anchor property of the control, and disable all anchors (or, through code, set the Anchor property to AnchorStyle.None).

The technique for each file type would be different. If you just prepend one file to another, most programs will probably only open the prepended data (based on the header from the prepended document) and ignore the remaining data. To do this properly, you have to work with the format of the documents. With office documents you could probably just interop with office. With audio and video files you would probably need special libraries, and even then the particulars can vary from format to format. In other words, you are looking at alot of work.

Re: Misinterpreted guidelines Quite right. I can't believe that you are the first person to catch that. However, there are plenty of people (as you can see on this thread) that think that structs should be immutable. This is probably generally true, but there are certainly cases where it isn't. If the object is large it should probably be a class to avoid large copy-on-assign operations. Luckily for us, the only objects that can possibly vary in size are strings and arrays; all other types are fixed in size. This removes most of the guesswork, making it easier to determine whether a class or struct would be appropriate. IceAzul, I think treating structs as some sort of unsafe object would be making a mountain of a mole hill. With pointers, bad things can happen. With structs, a minor logic error can occur if you aren't particularly familiar with them. As far as mutable structs ruining fairy tale Type Land, I don't think this is the case. Structs should be used for a type of object that needs to be handled a certain way. The alternative, a struct that needs to be programmed a different way, is hardly more unified. In my programming, though, I find the availability of stack-allocated, copy-on-assign, mutable objects very important. Perhaps the reason that so many people disagree is because they don't spend so much time getting their hands dirty with binary/raw data. Nerseus, I'm just guessing here, but the reason you are looking for is probably the one I mentioned in my second post, which would be the confusion caused by manipulating a value on the stack and thinking you are manipulating data within a class.

I understand what you are saying, and it makes sense. The problem I addressed with String.Replace and DateTime.AddX is the combined result of their immutability and more importantly the poorly named/declared methods. With better naming, immutability might lead to less confusion with structs. Regardless, based solely on your argument, I still disagree with the statement that structs should be immutable. Ultimately, your argument breaks down to the opinion that structs should be immutable to avoid issues resulting from their being misunderstood. However, I propose another solution to this confusion: programmers should be educated as to how their programming language works. Problem solved. Easier said than done, I know. There is no way to make all C# programmers aware of how structs work as a result of copy-on-assign behavior and stack operations. I see it as more of a road bump that all programmers should hit, and then get over it. You run into the problem, figure it out (via reference material, FAQ, message board, whatever), and the problem is solved. If structs are only used where they belong and they are designed to be used as a struct should be used then the problem they present will be minimal. And while I support the seemingly more difficult school of thought, I do so for the sake of being able to use structs to their fullest potential. When used properly, structs are great for binary data access and can be more resource efficient. Microsoft didn't just make "another kind of class" for the hell of it, and structs work the way they do for a reason. Except, perhaps, for a few rare circumstances, if you find that your struct needs to be immutable to work intuitively then you should be using a class. If you are thinking of an instance of a struct as an object (despite the fact that they derive from System.Object) your should be using a class. Thinking in terms of objects is, I think, where this confusion comes from. A struct really isn't an object. It is a value (probably a composite value, but a value none the less).

Actually, using an ArrayList, the code you posted would work as you originally stated because, like the Form.Bounds example I posted, getting an element from an ArrayList uses an indexer, which is a property, which is ultimately a function call, so you place the rect on the stack, modify it, and discard it without effect, thinking you have set its width. But, still, making the struct immutable doesn't really protect you from doing this by accident, as far as I can see. Quite the contrary, I've seen a number of posts (and, embarrassingly, found myself confounded on several occasions by the same exact problem) where people couldn't get the String.Replace function or DateTime.AddX to work because it returns a new object rather than modifying the object on which the method was invoked.

To see if the elipse has been clicked on there are a few techniques you could use. If you are using an Image to buffer the PictureBox and you are drawing a solid ellipse, you could check the color of the pixel the user clicked on. A better option would be to store the location of the ellipse. You can use a geometric formula to determine if the point clicked is contained within the ellipse (if the ellipse is a circle, a simple distance formula would work). As to the question of the click event, it sounds like you want to surpress it. To do so you would probably need to inherit the class and override the OnClick method. However, it will probably be better (and easier) to include an if statement inside the handler that only executes under desired circumstances. Instead of using the Click event, you could use the MouseDown or MouseUp events (or a combination of the two) so that you can examine the position of the mouse and decide whether or not to react (or how to react).

The code you linked to is C++. Have you translated it? If so, could we see your translated code to try to identify the problem?

When the code is compiled, for any reference that is made to any type the IL explicitly declares the name of the module, namespace, and the class that is being referenced. I'm curious to see what the compiled IL looks like. I don't see how there can any sort of naming conflict. Could it possibly be a versioning issue? Would it be possible for you to use Reflector to decompile the code that is throwing the exception and post it here?

I can't image what computer would not come packed with Arial... regardless, you can include the font file as an embedded resource and either load it into your application (I think you can only use it for GDI+ in this case, not for fonts on controls) or you can install it into Windows (I don't know the specifics of this). However, there is still the issue of licensing. If you are not licensed to distribute this font then it may be technically illegal for you to do so.

It might be more work, but you could try an owner-drawn ListBox. It isn't really that much work.

That is not true. Look at the following console app I wrote: C# Code[HorizontalRule]magic hidden text[/HorizontalRule]// Create Rectangle array and initialize first element Rectangle[] rects = new Rectangle[10]; rects[0] = new Rectangle(1, 1, 1, 1); // Display first element Console.WriteLine(rects[0].ToString()); // Modify first element, and display again rects[0].Width = 999; Console.WriteLine(rects[0].ToString());[HorizontalRule]Why are you quoting me?[/HorizontalRule] The output is as follows: 1, 1, 1, 1 1, 1, 999, 1 [/Code] What you are probably referring to is something more along the lines of: [Color=Gray][size=1]C# Code[/size][/Color][HorizontalRule]magic hidden text[/HorizontalRule][Font=Courier New][Color=White][/Color][Color=Green]// Code inside a Form[/Color] [Color=White][/Color][Color=Blue]this[/Color][Color=Red].[/Color]Bounds[Color=Red].[/Color]Width [Color=Red]+=[/Color] 20;[/Font][HorizontalRule]Why are you quoting me?[/HorizontalRule] The above code would place the bounds on the stack, change the value, then pop it off without effect. This would be a logic error, but a very understandable one. For this reason, C# will actually not compile the code above. If you need to change only one aspect of the Bounds, in this case, the Width, then a struct is not what you need (hence, they provide a Width property for the Form class). Structs have value-type behavior. Pulling a struct from a property and modifying it without assigning it back is just like pulling an int from a property, modifying it, and not assigning it back. The code below does just that. Note how nonsensical it looks. In this light, the code above looks almost as silly to me as the code below. [Color=Gray][size=1]C# Code[/size][/Color][HorizontalRule]magic hidden text[/HorizontalRule][Font=Courier New][Color=White][/Color][Color=Green]// Code inside a Form[/Color] [Color=White][/Color][Color=Blue]this[/Color][Color=Red].[/Color]Width [Color=Red]+[/Color] 20;[/Font][HorizontalRule]Why are you quoting me?[/HorizontalRule] If you understand how a struct works, you will quickly get over this problem. You might think it results in inconvenience or clumsy code. If this is the case, you are probably using structs where you shouldn't. Many features of C# have the potential to be abused. Structs are not unique in this aspect. Classes have a tendency to be more intuitive. In my programming, however, I have found structs to be pretty handy plenty of times (binary data manipulation, image manipulation, etc.) and they wouldn't be if they were immutable. But, alas, I've hardly addressed how any of this relates to immutability, so, let's answer the question: "How will making a struct immutable solve this problem?" Let's pretend that the Rectangle struct is immutable, like the string class is. You can't change part of it. You need to use a function to get a new object that represents the modification. Let us add the Rectangle.ChangeWidth function. Like the String.Replace function, it returns a new, modified object. So, now, let's try to change the Form's width: [Color=Gray][size=1]C# Code[/size][/Color][HorizontalRule]magic hidden text[/HorizontalRule][Font=Courier New][Color=White][/Color][Color=Green]// I would still feel inclined to write code like the following,[/Color] [Color=White][/Color][Color=Green]// which would be bound to fail.[/Color] [Color=White][/Color][Color=Blue]this[/Color][Color=Red].[/Color]Bounds[Color=Red].[/Color]ChangeWidth[b]([/b]100[b])[/b]; [Color=White][/Color] [Color=White][/Color][Color=Green]// In order for this to work, we still have to use the struct in[/Color] [Color=White][/Color][Color=Green]// unpleasant, less intuitive manner.[/Color] [Color=White][/Color][Color=Blue]this[/Color][Color=Red].[/Color]Bounds [Color=Red]=[/Color] [Color=Blue]this[/Color][Color=Red].[/Color]Bounds[Color=Red].[/Color]ChangeWidth[b]([/b]100[b])[/b];[/Font][HorizontalRule]Why are you quoting me?[/HorizontalRule] Okay, I'll admit that it looks nicer than using an intermediate variable and changing the width over three statements (read property to variable, modify variable, assign back). But this is not really a benefit of immutability. This hypothetical function does not require immutability, but rather immutability requires it. What's more, we have now provided an option that will result in a logic error that the compiler [i]will[/i] compile. And in the array example I gave at the top the syntax actually gets clumsier. So, immutability forces us (rather than leaving us the option) to design structs such that they can be used with fewer statements and intermediate variables, resulting in prettier code, yet still does not make said structs foolproof. Is this the end result you hope to achieve with immutability? Of course, all this is said with the assumption that I correctly identified the potential risk you identified with mutable structs. This perceived problem is really the result of poorly used or misunderstood structs, but I don't see how immutability alleviates the problem.

According to MSDN,

Which view are you using? Curiously, when using the "List" view, the ListView scroll horizontally, and all other views (small icon, large icon, details, etc) scroll vertically. There is no option to modify this behavior. This can be seen in Explorer as well as any other application that uses a ListView. I think you are stuck with it.

Using SelectedItems would only enumerate selected items. Assuming you would like to enumerate all items, you should use the Items property.