snarfblam

Not sure if this is what you are looking for, but it is something: Lossless JPEG Rewrites in C#. Information seems to be surprisingly scarce on the net for this topic.

Well, we can only beat a dead horse for so long. Just let me ask this one question, Nerseus (or PD, or whom ever). Would wrapping the 1.x library and using it through 2.0 require that the end user has DotNet 1.x installed? Of course, I don't expect it to be an issue, but from a purely academic point of view it would be a shame to depend on two versions of the framework.

(Addressing question 1) The code worked fine for me. What do you mean you have to press both buttons too tight? Maybe it would seem more responsive if you used the KeyDown event instead of KeyUp.

You clearly disagree with IngisKahn, but I agree with him. Given your standard scenario: As written you are doing plenty of blocking, but there is no need for it. There is no need for you to call the stored procs on the UI thread. If there is any kind of snag, all windows in the application will stop responding (at least, momentarily). No, its not the end of the world but it isn't necessary and it is frustrating. When a program does this to me it strikes me as a broken UI. Why are you so bent on writing code like that above instead of something like: Form loads (preferably constructor): Begin Async Calls Do some initialization that doesn't require data Async Completes: Bind controls Display Form Think about it...

When updating the bounds of UI objects, it is best to do them all at once. It will reduce flicker and if a large number of updates are made, they will go much more quickly. Ideally, the code should read something like: OKButton.Bounds = [color="Blue"]New[/color] Rectangle(81, 165, 22, 65) If you just wanted to change the size, or just wanted to change the location, code like that posted by Nerseus would be best. If you just want to change one aspect of the bounds, just the X or Y or width or height, then you would use the Left, Top, Width, or Height properties (respectively). The reason that you can't use the OKButton.Location.X property is rather technical, but it should suffice to say that you although you can't modify part of the Location (or size) properties, you can assign a new Point or Size object to those properties.

Nerseus, I must be missing something or misunderstanding something here, because it is not like you to be so confused about something like this, and I consider myself a multi threading novice.

And you are calling Debug.Print inside the event handler? Do you have WorkerReportsProgress set to true? I copied and pasted your code, stripped out all the web functionality, changed a couple of things because I don't have your form with your controls, and I ended up with this: [Color=Blue] Private Sub[/Color] Downloader([Color=Blue]ByVal [/Color]sender [Color=Blue]As [/Color]System.Object, [Color=Blue]ByVal [/Color]e [Color=Blue]As [/Color]System.ComponentModel.DoWorkEventArgs) [Color=Blue]Handles [/Color]BackgroundWorker1.DoWork GetIndex() [Color=Blue]End Sub[/Color] [Color=Blue]Private Sub [/Color]Download_ProgressChanged([Color=Blue]ByVal [/Color]sender [Color=Blue]As [/Color]Object, [Color=Blue]ByVal [/Color]e [Color=Blue]As [/Color]System.ComponentModel.ProgressChangedEventArgs) [Color=Blue]Handles [/Color]BackgroundWorker1.ProgressChanged ProgressBar1.Value = e.ProgressPercentage [Color=Blue]End Sub[/Color] [Color=Blue]Private Sub [/Color]Download_Completed([Color=Blue]ByVal [/Color]sender [Color=Blue]As [/Color]Object, [Color=Blue]ByVal [/Color]e [Color=Blue]As [/Color]System.ComponentModel.RunWorkerCompletedEventArgs) [Color=Blue]Handles [/Color]BackgroundWorker1.RunWorkerCompleted Text = "COMPLETE" [Color=Blue]End Sub[/Color] [Color=Blue]Public Sub[/Color] GetIndex() [Color=Blue]For [/Color]i [Color=Blue]As[/Color] Integer = 0 [Color=Blue]To [/Color]99 BackgroundWorker1.ReportProgress(i) System.Threading.Thread.Sleep(100) [Color=Blue]Next End Sub[/Color] [/Code] It looks pretty different, but the multi-threading aspect is identical, and it works just fine. Perhaps you have a property set wrong or an event handler that you forgot to attach, or something along those lines.

Have you considered using jagged arrays? With jagged arrays you can treat different "rows" (if that is how you prefer to think of it) independently. For example... [Color=Blue]Private Sub [/Color]Button1_Click([Color=Blue]ByVal [/Color]sender [Color=Blue]As [/Color]System.Object, _ [Color=Blue]ByVal [/Color]e [Color=Blue]As [/Color]System.EventArgs) [Color=Blue]Handles [/Color]Button1.Click [Color=Green] 'Create empty array that can hold 3 rows [/Color] [Color=Blue]Dim [/Color]Test [Color=Blue]As [/Color]String()() = [Color=Blue]New [/Color]String(2)() {} [Color=Green] 'Create and populate rows.[/Color] [Color=Blue]For [/Color]i [Color=Blue]As Integer [/Color]= 0 [Color=Blue]To[/Color] 2 Test(i) = [Color=Blue]New [/Color]String(2) {} [Color=Green]'Create a row with 3 items[/Color] [Color=Green] 'Populate row[/Color] [Color=Blue]For [/Color]j [Color=Blue]As Integer [/Color]= 0 [Color=Blue]To [/Color]2 Test(i)(j) = Chr(65 + j + i * 3)[Color=Green] 'Set a single, unique character.[/Color][Color=Blue] Next Next[/Color] OutputArray(Test) MessageBox.Show("Click OK to swap") [Color=Green] 'Swap two rows [/Color] [Color=Blue]Dim [/Color]placeholder [Color=Blue]As [/Color]String() = Test(1) Test(1) = Test(0) Test(0) = placeholder OutputArray(Test) [Color=Blue]End Sub[/Color] [Color=Blue]Sub [/Color]OutputArray([Color=Blue]ByVal [/Color]data [Color=Blue]As [/Color]String()()) txtOutput.Clear() [Color=Blue]For [/Color]i [Color=Blue]As Integer [/Color]= 0 [Color=Blue]To [/Color]UBound(data) [Color=Blue]For [/Color]j [Color=Blue]As Integer [/Color]= 0 [Color=Blue]To [/Color]UBound(data(i)) txtOutput.Text &= data(i)(j) & "; " [Color=Blue]Next[/Color] txtOutput.Text &= Environment.NewLine [Color=Blue] Next End Sub[/Color] [/Code] Another option might be to use Array.Copy to copy data from one row to another, provided that there is a relevant overload present. This would also require a second 1-D array to act a buffer.

I'm sorry, but what do you mean when you say "change controls on the main form within it?" Also, what happens if you use Debug.Print in the ProgressChanged event handler? (Or, in other words, does program control ever reach the event handler?)

And, no, you aren't being an idiot. One of the biggest criticisms of VB6 is that it teaches "bad habits." It uses "dumbed down" and uncommon techniques that are not usually there in other languages, not even other versions of BASIC. 90% of these peculiarities were eliminated in VB.NET (and kept out of its close cousin, C#), but the end result is that it is significantly different which can pose a challenge. Good luck with the cross-over.

Or, to be more general, remove the resource the same way you added it. If you simply directly added it to the solution explorer, you should be able to simple directly delete it. If you use the resource editor to add it, use the resource editor to remove it. If it is a local resource, such as an image on a button, it should automatically be deleted when the resource isn't needed, such as when you change or remove the button image. [Edit]If you add an image as a project resource through a Form designer it would need to be removed through the Resource editor.[/Edit]

This is a common misconception with the Express editions of VS. There is an option to enable the familiar Debug/Release configurations. It is simply disabled by default. Either way, the Build Events should be sufficient. A very handy and easy way to post-process your compiled app. All you have to do is write a very simple batch file that will copy your files. I can't imaging that this would be harder than manually copying the files each time. It is one line of code and in the end you will certainly save time.

Judging by the nature of your question, I think you would greatly benefit from a better understanding the concepts of program flow and threading. With the typical single-core single-CPU computer only one thing can happen at a time. Things can be done in a way that makes it seem like more than one thing can happen at a time, such as alternating between different tasks (threads) or doing tasks so quickly that they all seem to happen at once. Even with multiple CPUs/cores, a properly multi-threaded application probably wouldn't allow all employees to clock in at the same time, but instead it would probably make all other employees wait while it processed one at a time.

If you remove the image from the picturebox (right click the value of the Image property in the designer and select "Reset") does the resource not get removed from the resource file?

This is assuming that we are using a 2.0 version of VS. If you are using version 1.x you need to add the icon to your project, set the compile action to embedded resource, and use the Assembly.GetManifestResourceStream function to get a System.IO.Stream object that you can pass to the System.Drawing.Icon constructor. Of course, you will need more than a brief summary of the process, but I believe that there is a tutorial in the Tutor's Corner section of the forum.

I've seen certain questions asked a number of times and decided that it would be appropriate to have some reference that clearly explains the details of this tricky aspect of function calls. To get the most out of this you should understand the concept of pointers and the difference between value-type objects and reference-type objects. Pointers, Pointers Everywhere Like traditional VB, DotNet languages (C++ aside, this article will focus on VB and C#) do an excellent job of hiding pointers from the programer, despite the fact that they are a very fundamental aspect of DotNet programming, used with reference types, pass-by-reference parameters, Delegate objects, and unsafe C# code. In order to understand the intricacies involved in all of these aspects of programming, however, the programmer must be aware of how pointers play into DotNet programming. Reference types Ultimately, references are dumbed down pointers. Of course, this is not an insult at our programming ability, but it is necessitated by our programming paradigm. DotNet is intended to be a purely object-oriented programming language, and memory addresses, dereferencing, and pointer math don't fit the bill. The downside, however, is that it is easy to forget (and just as easy to never realize in the first place) that we are using pointers. A variable that holds a reference to a DotNet object actually simply holds a pointer to that object. A reference is a pointer. See Figure 1, which pictures a value type variable, which directly holds data, and a reference type variable, which holds a pointer to data. Handles Okay, I lied. DotNet references aren't pointers. They are handles. So, what is the difference? In general, the difference between a pointer and a handle is that a pointer contains an actual memory address, whereas a handle contains a value which identifies a resource. This value may be a pointer. It may not. (In fact, you could think of a pointer as a type of handle.) The point is that the term "handle" stipulates certain behavior (a subset of the features and behavior of a pointer). Handles are usually some kind of pointer, quite often a pointer to a pointer, though they can be as simple as the index of an object in a list of objects. But DotNet handles are actually pointers to runtime data for our DotNet objects (which is actually stapled onto the beginning of our objects in memory), so for the sake of this discussion the statement that DotNet references are pointers is sufficiently accurate. Pass-By-Reference Arguments Arguments are passed to functions on the stack. When you pass an argument to a function by reference (using the ref or out keywords in C# or the ByRef keyword in VB) a pointer to the argument is placed on the stack instead of the object itself. This behavior allows us to prevent large objects from having to be copied to the stack and allows the function being called to write back to the original variable. The Confusion The question I see all too often is whether or not there is any difference between passing a reference object by reference versus passing a reference object by value. Either way you are passing a pointer, right? So there is no difference, right? And, of course, we would not be right. Let is investigate some different scenarios involving reference types, value types, and by-reference and by-value arguments. Of course, DotNet does a great job simplifying things, so all of these scenarios would look very similar when written in code, but the resulting compiled code would look pretty different (and it very well could behave equally differently). Value-Type Pass-By-Value This is a very simple and relatively common way of passing arguments to a function. This is how one usually passes an integer, a Rectangle, an enumeration, or any other value type object. The object itself is copied onto the stack. It may be examined by the callee (the function that is being called), but the original object can not be modified because the object passed to the callee is a copy and changes will not be reflected in the original. See Figure 2a. Value-Type Pass-By-Reference This is a much less common way to pass arguments to a function. Any time you see the word "reference," think pointer. Instead of copying the object onto the stack, a pointer is placed on the stack which points to the original object. This means two things. Firstly, the callee has direct access to the original object via the pointer and may freely modify its value. Secondly, large objects will not need to be copied, which may improve performance (though you would need to see a huge number of function calls with large numbers of large objects in order for this to be truly advantageous). See Figure 2b. Note that the original data can be accessed via the pointer on the stack. Reference-Type Pass-By-Value This is another common way to pass arguments to a function. Since we are using a reference-type object, we will place a reference on the stack. And what is a reference? A pointer! So we will be placing a pointer to an object on the stack. Say, does that sound familiar? It does! That is exactly what we did when we passed a value-type object by reference. There is an important difference though. There are certain restrictions imposed upon us with reference-type objects that aren't there with value-type objects. For instance, would could copy the data from one Rectangle object directly to another Rectangle object. We don't have this kind of direct access, however, with reference-type objects. Not because it is not possible, but because DotNet doesn't allow it. We can only access reference-type objects via public properties and methods. If it weren't for these restrictions, reference-type passed by-value would be exactly the same as value-type passed by-reference. See Figure 2c. Note that the end result on the stack is essentially identical to that of figure 2b. Reference-Type Pass-By-Reference This exceedingly rare creature is the most confusing of them all. See that we have the word "reference" in there twice? Two references means two pointers. Or to be more specific, a pointer to a pointer. The fact that we have a pointer to a pointer means that the callee (the function being called) has direct access to the reference that was passed into the function. In other words, the callee can change the reference and cause it to point to something else. No other argument marshalling mechanism provides this (rarely useful) capability. You can pass a Form to a function, and after the function is called, your variable that referenced said form could, for all you know, reference a completely different form. This, however, is the only difference between reference by-value and reference by-reference. See Figure 2d. Note that the stack contains a pointer to a pointer, allowing us to modify what that pointer points to. In And Out C# offers a parameter marshalling scenario in addition to the default pass-by-value mechanism and the pass-by-reference mechanism (using the ref keyword). Although it isn't essential to understanding the difference between by-value and by-reference mechanisms, it is related and I will cover it anyways to complete the article. C# allows parameters to use the out modifier as an alternative to the ref modifier (or no modifier at all). The out modifier specifies that a variable is passed-by-reference (i.e. a pointer is placed on the stack), but stipulates that the variable isn't necessarily initialized when it is passed into a function, and that the variable must be initialized before the function is finished. The purpose is to provide a mechanism that allows a function to return more than one value. Although this would be possible to do with a ref parameter, using an out parameter forces the function being called to return a value through the parameter. From within the function being called it would be an compiler error to not return something through an out parameter, and it would be a compiler error to read the value of the out parameter before assigning to it.

You can do whatever you like when the user presses F1. The important things you need to know are: The HelpRequested event is raised when F1 is pressed. You handle this event in any way you like. Be sure to set the HelpEventArgs.Handled property to true if you handle the event. The HelpRequested event is actually intended to be used for context-sensitive help and can also be raised by clicking the question mark button in the title bar if this button is displayed on your form, so make sure that you don't require the use of this feature if you choose this solution.

Holy wow. Never noticed this new property. It wasn't there in 2003 and I haven't used a passworded TextBox since. The link I posted addresses the issue in .Net 1.x. OMID SOFT's recommendation will work on newer versions.

What you want to do is call the Form.Invoke method on the Form that you want to update. The Form.Invoke method ensures that the method being invoked is processed on the application's main thread. [Color=Blue]Private Sub[/Color] SerialPort1_DataReceived _ ([Color=Blue]ByVal [/Color]sender [Color=Blue]As [/Color]Object, _ [Color=Blue]ByVal [/Color]e [Color=Blue]As [/Color]System.IO.Ports.SerialDataReceivedEventArgs) _ [Color=Blue]Handles [/Color]SerialPort1.DataReceived [Color=Green]' If we receive any character then... [/Color] [Color=Blue]If [/Color]e.EventType = IO.Ports.SerialData.Chars [Color=Blue]Then[/Color] SomeFormThatContainsLabels.Invoke( _ [Color=Blue][Color=Blue]AddressOf [/Color][/Color]ProcessData) [Color=Blue] End If End Sub[/Color][/Code] Haven't tested that, but it should at least give you an idea.

Who says that it is not recommended to enable KeyPreview, and why? It isn't necessary in this case, though. It seems that the active control, its container, its container's container, etc., will all raise the HelpRequested event when the user presses F1 (this includes the active form). I recommend that you create a static class that will handle all of the Forms' HelpRequested events, that way you can have a small amount of code in one place that handles this feature. You can either create a new Form class that does this and derive all 84 of your forms from that or you can add a statement to each form's constructor that adds that form's HelpRequested event to the class' HelpRequested event handler. Beware, though, that this event seems to be raised more than once when the user presses F1. When you handle the event, be sure the set the HelpEventArgs.Handled property to true to prevent the event from being raised again.

What an amazing coincidence. I just stumbled on this PasswordBox Control yesterday, which addresses, among a couple others, this issue.

Actually, the DrawString method will properly wrap the string if you specify a RectangleF to draw the string in instead of only an x and y. e.Graphics.DrawString(ReportTextBox.Text, _ [color="Blue"]New[/color] Font("Arial", 10, FontStyle.Regular), _ Brushes.Black, _ [color="Blue"]New[/color] RectangleF( _ [i][color="Red"]LeftMarginX[/color][/i], _ [i][color="Red"]TopMarginY[/color][/i], _ [i][color="Red"]SpaceBetweenMarginsX[/color][/i], _ [i][color="Red"]SpaceBetweenMarginsY[/color][/i] _ )) [/Code] You just need to calculate and substitute the values shown in red. You already know the [i][color=Red]LeftMarginX[/color][/i] and [i][color=Red]TopMarginY[/color][/i], you just need to determine the space between the margins.

The best way to find out if something works is to try it. An important part of programming is testing and debugging. (If you are working on an application that prints, then you should be willing to sacrifice some ink and paper.) If you are worried that your code is not sound and may cause an error, the best thing to do would be to use that code and try out different scenarios. Use your program and try to cause an error. Think about possible problems such as what would happen if there is too much text to fit on a page, or special characters that might not print correctly, and try them out.

Not sure if you are looking for help with graphics or with math, so here is both. Basically you are converting between two Cartesian coordinate systems. This isn't exactly true, because the earth is not flat and traveling north 100 miles then east 100 miles will get you to a different place than traveling east 100 miles then north 100 miles, but if the map is a small enough scale, this shouldn't be a big problem. You need to figure out the scale and offset. How many pixels equals how many meters (this may be different for horizontal coordinates and vertical coordinates), and where is the "northing"/"easting" point 0,0 on the map image? Once you know these things you can use a standard Cartesian coordinate conversion formula. Say you determine that each pixel equals one kilometer. The scale is 1 pixel = 1000 meters (but since "northing" counts up going north and pixel coordinates count down going "north" the Y scale is 1 pixel = -1000 meters). And say the "northing"/"easting" location of 0,0 appears on pixel 0, 200 on your map. Your scale is 1,1 : 1000,-1000 and your offset is 0, 200. So, say you have the easting = 20,000 meters and northing = 25,000 meters. First you multiply by the scale (see image... algebra rocks). Of course, you don't need to use the units when you do the math in your program, but on paper it helps you sort out what gets multiplied by what and what gets divided by what. Then you take the scaled coordinate (20, -25) and you add the offset (0, 200) and you get (20, 175). Your physical location (20000, 25000) translates into screen coordinates (20, 175). You want to load the image (of course). This is simple enough (C#: Image myImage = new Image(filename). Like I said, the earth is round, so you might need to modify the math a little, but once you get the coordinates, you just create a graphics object (use Graphics.FromImage(myImage)) and use that to draw your dot. Say you want to draw a red circle at 20, 175 with a radius of 5. You would do this: C# int x = 20; int y = 175; [color="Green"]// Note that you offset the coordinate in // order to center the dot.[/color] myGraphics.FillCircle(Brushes.Red, x - 2, y - 2, 5, 5); [color="Green"]// Color, x, y, width, height[/color] Hope that helps, rather than confusing you. For me math and graphics come very easily, but not everyone is me.

If you want a quick and dirty hack, you can use a MenuStrip, create a ToolStripMenuItem for each shortcut key, attach a handler, and then set the MenuStrip's visible property to false. Like I said, it is a quick and dirty hack. I would never use it, but its there.