snarfblam

My company would be whatever the assembly's company is set to. I don't know about c++, but in C# and VB there is a designer that lets you set these values (in code they are in the form of attributes applied to the assembly).

What version of VB are you using? How did you create the combo box and where did the data come from? Is there any other relevant code that you should maybe post? What is the DropDownStyle property set to? Which properties have you changed?

As much as C# and VB change over each version, for the most part they remain backwards compatible and for anyone who is that opposed to change, they can just ignore the new features (easier said than done, but if you are stubborn enough, it is do-able). The fact that Java tends to be so slow to change can be a weakness. Java's generics, for example, were implemented in a way as to work with the pre-existing runtime, and as a result they offer no gain in performance, some unusual restrictions, and no support for generics in reflection. All because they didn't want to change the byte code standards. JavaBeans, Java's implementation of properties, another feature designed to work with pre-existing Java runtime, is a complete mess. The property name you see in a designer is not the same as it is in code. The property "Text" in the IDE might appear as a get/set combination in code, or the functions could be (and sometimes are) named completely differently. Again to avoid changing the standards. When the world of computing is always moving ahead I would say it's suicide to avoid change.

You can also create your own intermediate form and call the ShowDialog function of that form, which pauses execution on the calling thread until the form is hidden or closed. A third option would be a multithreaded approach, where you could load all the files on a secondary (non-gui) thread and for each file, block the thread until the user clicks OK for each file. At this point, though, there would also be single-threaded options that could also provide the same functionality.

If you want more quotes from Diesel all you really have to do is click "Get New". They just keep coming.

Can you post some code that accesses these arrays? It looks like there is some tricky marshalling going on here that could be causing you some problems.

Is the other app .Net?

Escape sequences? The backslach begins an escape sequence. \r is carrige return. \n is newline. For each backslash you want to place in a string, type in two: \\. System::String path = "C:\\Documents and settings\\things and stuff\\file.exension"

Maybe I should clarify what I meant about the control variable. There are plenty of times you might use a While loop without a control variable, but in terms of a for-style loop, usually (probably almost always) the loop will contain dynamic code that depends in the iteration number. How often do we find ourselves repeating a completely static task? Either way, the option will be there to loop with no control variable.

I would use conditional compiling. Have one filename for the debug build and another for the release build. #if DEBUG const string filePath = @"C:\Document And Settings\Thor\My Documents\Test.txt"; #else const string filePath = IO.Path.Combine(Application.StartupPath, "things.txt"); #endif

I have a feeling that alot of the answers will be the same. When I began to learn .Net, I ran into a problem (what specifically, I forget). A google search brought me here. Next time I ran into a problem I remembered this website, opened up the history, found it, signed up and asked my question. Here I am, 1000 posts later.

If you want to display a floating point number and make it look pretty, you should use a .ToString overload that supports formatting and rounding. The roundoff error will essentially dissappear. You should never compare doubles for equality. Not only is there a roundoff error, but the accuracy of the calculations is not set in stone. Where in .Net version 1 there may be 15 digits of precision, in .Net version 2 there could be 18, which means that .Net 1 will give you a slightly different result than .Net 2. The best thing to do is have some tolerance when you want to see if two doubles have the same value. // A difference smaller than this will be considered equality const tolerance = 0.000001; double A = 4; double B = 16.0 / 4.0; bool isApproximatelyEqual = Math.Abs(A - B) < tolerance; MessageBox.Show("A equals B: " + isApproximatelyEqual.ToString()); No matter how many people discover this and report it as a bug, the fact will always remain: this is by design.

I have considered the situation, and regardless of which of the loop constructs I implement, chances are that there will be optional parts to the loop. For example, take loop construct #3 from my original post. We could enhance it as so... [color=DarkGreen] // loop([[i]controlVariable[/i], [[i]start[/i], ]] [i]iterationCount[/i]) {} // default value for [i]start[/i] would be 0. // default value for [i]controlVariable[/i] would be an unnamed hidden variable. // Giving us the ability to write code like the following: [/Color] [color=Blue]loop[/color](10) { [Color=DarkGreen]// Show static message 10 times[/Color] [color=DarkRed]MessageBox[/color].Show("0123456789"); } [color=Blue]loop[/color](i, 10) { [Color=DarkGreen]// 10 iterations = 0 to 9[/Color] [Color=DarkGreen]// Show numbers 0 to 9[/Color] [color=DarkRed]MessageBox[/color].Show(i.ToString()); } [color=Blue]loop[/color](i, 1, 10) {[Color=DarkGreen]// 10 iterations starting at 1 = 1 to 10[/Color] [Color=DarkGreen]// Show numbers 1 to 10[/Color] [color=DarkRed]MessageBox[/color].Show(i.ToString()); } Frankly, the more and more I program, the less and less I find myself doing a loop where a control variable isn't necessary. Of the top of my head I can't really see when this would be particularly useful (I'm not saying it wouldn't be, if you have an example, I'd love to see it, if for no other reason than out of curiousity). The idea is that the real treat would be something like this: for(int i = 0; i < value.Length; i++){ MessageBox.Show(values[i]); } // BECOMES loop(i, values.Length) { MessageBox.Show(values[i]); } I know that C# has a foreach loop. We aren't really talking C# here, though, but rather my own command interpreter syntax.

VB just does it for you. The same thing doesn't happen in C# so it must just be a feature of VB. You type "Implements IDisposable" and it throws in a snippet.

You could "pin" the window. Click the little tack icon (tooltip says "AutoHide" and it will minimize itself to a tab whenever it doesn't have focus. That way you never have to see it unless you want it. It might be possible to create a macro too.

The easiest thing I can think of is to use images for your checkboxes. I don't know why there isn't a property on the TreeNode class to have a checkbox.

I've tested both methods on the linked-to page. The most important thing to note is that they do not behave the same way. The second will copy the image of a control directly off the screen. This means that it will work for a rich text box. The drawback is that since the image is copied from the screen, if the control is not completely visible (i.e. is hidden, partially or completely covered by another control or window, or out of the bounds of the screen or its container) it will not be drawn as excpected. The first actually gives the control a device context to render to exactly as it would render itself to the screen. This means that a control that supports this function will always draw itself successfully regardless of how it appears on the screen. It also means that you can't use it to draw a RichTextBox because the RichTextBox does not support DrawToBitmap. (It also draws forms as though they are unfocused.)

Simply put, cast a randomly generated number to a MoveDirection value. Random rand = new Random(); // You need to crop the range to 0...3 since your enum's // integer values are 0, 1, 2, and 3. MoveDirection whichWayToGo = (MoveDirection)(rand.Next() % 4); MessageBox.Show(whichWayToGo.ToString());

That's why I supposed the answer would depend on a user's language of preference. #1 is a VB style loop, comfortable to people who use VB exclusively. #2 is a normal loop, comfortable to anyone who uses something besides VB. And #3 I just threw out there. Throw it into C# and it would probably never get used. It could, possibly, maybe, be a little more useful in a scripting or immediate execution context. Say you were to display output (a list of files, a summary of a long operation, etc.) twenty lines at a time, something like this... function showOutput(string[] lines){ for(int i = 0; i < lines.Length; i += 20) { // Loop through lines 20 at atime for(int j = i, j < i + 20<, j++) { // Show next 20 if(j < lines.Length) WriteLine(lines[j]); } WaitForKeyPress(); } } ...could be written as... function showOutput(string[] lines){ int i; while(i < lines.Length){ // While there are lines left to show loop(i, i, 20) { // Show next 20 if(i < lines.Length) WriteLine(lines[i]); } WaitForKeyPress(); } } ...but the first is a little neater and more to the point. In other words, loop(x, x, y) would be a convinient way to say "take the next y items," and without the need to manage a second control variable. Nifty, but I'm not sure how useful.

No one said he made it up and no one said don't try it. His program will work just as he said, with the exception that the first method won't work with rtf boxes and the second may not work for rtf boxes. To me, "may not" implies "try it and find out."

I can guaruntee you that the first solution on the page you linked to won't work. RichTextBox does not support DrawToBitmap. I don't know why it isn't supported but I'm guessing that for the same reasons that RichTextBox doesn't support DrawToBitmap, the second solution might not work either. That's just a guess though.

Simply put, C++/CLI has everything that C# has, and it has everything that C++ has. So why every use C#? Because it is so much easier than C++/CLI since it is designed specifically for .Net. Or because there is more support for C# programmers. "Powerful?" What does that mean? Good performance? Arguably, I'd say C++/CLI wins. More flexible? C++/CLI wins, and by a larger margin on that one. Does that make it the right choice? Most .Net programmers would say no as it seems in my experience. C# shines as far as RAD goes, and that's a powerful feature, one which is at the heart of .Net. Ultimately, I don't think something so subjective can be proven.

Are there any overloads (not sure what type of library we are looking at) or other similar methods like .FromBinary or .FromMemory or anything like that? Something that accepts an array of bytes or a stream? If the only option is a file then you are stuck with a file, which is most simply handled by copying the embedded resources to a file.

Why not double buffer the graphics. Either manually create a System.Drawing.Bitmap to back the control's image and use code like that form my second example, drawing to both the screen and the buffer so you never lose the graphics and still draw them efficiently. Short of that, I can't think of anything besides maintaining an array of all the points in the line and redrawing the entire line when the control is redrawn.

Windows uses carrige-return/linefeed line breaks, whereas Macs are just carrige-return and Unix is just linefeed (I believe). Many programs are flexible in the matter, but appearently not Windows Common Controls.