snarfblam

Well then I certainly have to agree with you. It is undoubtedly possibly to create a very decent multimedia/interactive app or game using Dotnet.

What if within in the thread that you want to cancel you check the System.Threading.Thread.CurrentThread.ThreadState property and if it returns ThreadState.AbortRequested abort the operation and clean up resources. I don't really know if this will work but it is worth a shot. It only makes sense to me that if a thread is to be aborted it must be done internally within that thread so that it can do things cleanly (i.e. free resources/update external/static objects).

I wouldn't count on it. Computers have always been getting faster and faster and there have always been those that said that higher-level languages will soon find themselves on level ground with mid- or low-level languages. The actual steps up are rare indeed though. The three major players are still ASM, C, and C++, as they have been for a very long time, and optimizing compilers can put C++ on level ground with ASM. C++ isn't merely marginally faster. It is a matter of how and when it is faster. Dotnet takes advantage of idle CPU time in a major way (primarily in terms of memory management). This allows .Net to perform certain tasks, such as tasks that require the allocation of large numbers of objects, faster. QB, VB, and now C# have always been perfectly acceptable candidates for RAD and hobby/amateur programming, but for game programming they aren't ideal. For a complex game there isn't a huge amount of otherwise-wasted CPU power, which means that Dotnet's memory management will fall behind. Fast execution can also be compromised by the likes of on-demand JIT compilation and managed-to-native marshalling (and vice-versa), not to mention the performance loss and larger memory demand as a result of a huge number of .Net wrappers for Windows and DirectX objects. What "lighting-quick" means is very subjective. Polygon counts are ever-increasing. The complexity of business applications and operating systems continues to grow. Can VB use Managed DirectX to draw a large number of polygons quickly? Sure. But C++ can do it better, and it can run the game logic faster. So, is the gap between managed (or interpreted or VM) and unmanaged code getting smaller? To be certain, yes. But will C++ be taking a back seat to VB. Not any time soon. What do you foresee that will accelerate advancement in computational technology so drastically? RAD software has always had an advantage over languages like C++ in the right situations. When has VB ever been a worse choice for a small business application? But there will also always be software and developers that push the limits of the hardware and for the foreseeable future that is beyond VB's reach.

If the HttpRequest class has no asynchronous methods, look into multithreading.

I know it doesn't seem as extreme here as the name implies (not on Friday afternoon, anyways), but welcome.

Either way, a standard hashing algorithm would be best, such as MD5. If you have to do hashing on both ends you know the result will be the same in both places.

A real quick and easy way to do this is to place a picture box within a panel. The picture box should size to fit the image. At that point all you have to do is handle mouse events. On MouseDown you want to record the mouse position, and on MouseMove you want to examine the difference between the original position and the new position and move the picture box that distance. This is the jist of it. You will probably want to take certain things into consideration, such as which buttons are being clicked. Dim DragX As Integer Dim DragY As Integer 'Grab the position on mouse down Private Sub imgPicture_MouseDown(ByVal sender As Object, ByVal e As MouseEventArgs) Handles imgPicture.MouseDown DragX = e.X DragY = e.Y End Sub ' Move the image based on mouse movements Private Sub imgPicture_MouseMove(ByVal sender As Object, ByVal e As MouseEventArgs) Handles imgPicture.MouseMove If (e.Button <> MouseButtons.None) Then Dim Location As Point = imgPicture.Location Location.X += e.X - DragX Location.Y += e.Y - DragY imgPicture.Location = Location End If End Sub You also might want to see if there is a way to double buffer the picturebox/container for smoother scrolling. (Try subclassing the PictureBox class and using the SetStyle method to set AllDrawingInWmPaint and DoubleBuffering to true in the constructor. Also consider scrapping the PictureBox-in-a-Panel idea and do your own drawing.) If you can't get it up and running to your satisfaction I'll be glad to offer more assistance.

Where do you want to catch this error? Wrap the code in a Try/Catch block where the catch argument type is OutOfMemoryException. I would like to give you specific help or advice but that is all I can really say going on what you've posted.

Are you positive that this method is being called on the same instance of Listener each time? Does anything change if you declare str and Test() statically (i.e. as shared)?

Are you doing a debugger step through to see these values? I can't imagine why this does not work. Is is possible that each time Test() is called it is being done on a different instance of Listener? And, out of curiousity, have you tried simply using the concatenation operator (&) yet? What happens when you try a very simple test case such as: MessageBox.Show(String.Concat("Message", "Box")) And what happens if you condense Test() into: Private Sub Test(ByVal sender As Object, ByVal Data() As Byte) str &= Encoding.ASCII.GetString(Data) End Sub

I would stay away from IsDate. Are you trying to parse the date or verify that it is valid? Either way, I would try DateTime.TryParseExact(). It allows you to explicitly specify the format you want and returns a boolean value that indicates whether or not it was parsed successfully (and uses a pass-by-reference parameter to return the parsed date).

I'm guessing that you are switching over from VB6. For starters, I recommend you keep option strict on. It will catch certain errors before you even compile. For instance, for your fifth line you are implicitly converting a CheckState value into a boolean which could result in undesirable behavior (in fact, you have this kind of problem in a few places in your code). The reason you are getting a bounds error is because on the 6th line you are accessing items in CheckedListBox1.CheckedItems using an index based on all the items. When you get to item #3 you looking at CheckedItems(2) when you should be looking it Items(2). ' This variable tracks if the user has okayed overwriting old files so we only need to ask once. Dim Overwrite As Boolean = False If Me.CheckedListBox1.CheckedItems.Count > 1 Then For i As Integer = 0 To CheckedListBox1.Items.Count - 1 ' You should explicitly compare the CheckState value to what you expect If Me.CheckedListBox1.GetItemCheckState(i) = CheckState.Checked Then ' Try to use clear meaningful variable names. When you are using a strongly typed ' language with intellisense there is very little need for hungarian naming conventions ' (i.e. starting variable names with "str," "int," etc. ' ListBoxes store items as System.Objects. You should convert them back to strings. ' Since the looping variable (i) is based on Items.Count and not CheckedItems.Count, you should be accessing items ' using the Items(i) property instead of the CheckedItems(i) property. Dim OldFilename As String = CheckedListBox1.Items(i).ToString() ' Determine new filename. Not sure exactly how you constructed the filename ' but you should make more use of the Path class to guaruntee file path manipulations ' are correct and the code is more readable. Dim NewFilename As String = Path.Combine( _ Path.Combine(Me.proj_dir.Path, dirStdDtl.Path), _ Path.GetFileNameWithoutExtension(OldFilename) & ".dwg") ' I rewrote this whole part of the code. It is clearer to me now but you should do what makes sense to ' you when it comes to the logical layout of code. If File.Exists(NewFilename) Then If (Overwrite) Then ' If the user has already okayed overwriting files just delete the old one. File.Delete(NewFilename) Else ' Otherwise ask the user. ' The "proper" .Net way of using message boxes is with the MessageBox class. ' Also, neither MsgBox() nor MessageBox.Show() return a string. This is another ' example of where option strict would help. Dim Response As DialogResult = _ MessageBox.Show("One or more detail(s) already exist in " & Me.proj_dir.Path & "." _ & Environment.NewLine & "Are you sure you want overwrite existing detail(s)?", _ "File(s) already exist.", _ MessageBoxButtons.OKCancel) 'Based on the response, either delete old file or abort the operation Select Case Response Case Windows.Forms.DialogResult.OK File.Delete(NewFilename) Overwrite = True 'User has okayed overwrite, don't ask again Case Windows.Forms.DialogResult.Cancel Return ' Just FYI. Same as 'Exit Sub' End Select End If End If ' Copy the file System.IO.File.Copy(OldFilename, NewFilename) ' Clear the check Me.CheckedListBox1.SetItemCheckState(i, CheckState.Unchecked) End If Next i End If There is a lot of criticism in there, but hopefully it helps your transition to VB .Net.

I believe that DirectX is only meant to capture the input of the active application. Perhaps you would be better off using the Windows API?

What is the problem? Why not check if the font is bold, and if so make it not bold, if not make it bold. Or, here is a niftier solution. This code toggles whether or not text is bold in one step. MyRTF.SelectionFont = new Font(MyRTF.SelectionFont, MyRTF.SelectionFont.Style ^ FontStyle.Bold);

TypeDescriptors and ICustomTypeDescriptors are use for serialization in the designer (i.e. property grid), but not when using .Net classes to serialize an object. .Net serialization uses reflection, whereas TypeDescriptors provide another method of obtaining information about an object (although TypeDescriptors typically use reflection internally anyways). To determine what is and isn't serialized you normally use (or don't) the NonSerialized attribute (System.NonSerializedAttribute).

A property is bold if it is supposed to be serialized and not bold if it is not supposed to be serialized. There is nothing you can do about that, but I think you can work with it. I know that this works with the property grid in the designer, but I'm not positive about the property grid in the toolbox. Suppose your property is named "Value". If you create a method with a boolean return type named "ShouldSerializeValue" the property grid will only bold the item in the grid if the method returns true. For example, if you have two properties named DefaultValue and Value, and Value should only be serialized if it is different from DefaultValue, ShouldSerializeValue should be defined as follows: [color=Magenta]<C#>[/color] [color=Blue]bool [/color]ShouldSerializeValue(){ [color=Blue]return [/color]Value != DefaultValue; } [color=Magenta]<VB>[/color] [color=Blue]Function [/color]ShouldSerializeValue() [color=Blue]As Boolean[/color] [color=Blue]Return [/color](Value <> DefaultValue) [color=Blue]End Function[/color] If that fails, your class can implement ICustomTypeDescriptor, which takes a lot of work but makes the property grid very customizable.

Microsoft recommends that you never lock certain types of objects (and with good reason). You should never lock an object unless it is completely within your control.

It would be ideal to make a better representation of your intent with you code. I don't know what Form1, Form2, and Form3 do--their names are not descriptive of their function--so it is hard to give a particularly relevant example, but Form3's constructor could take a boolean to indicate whether or not a certain type of information is displayed or an enumeration that indicates how to present data and input controls. For the sake of an example, let's say that Form1 should open Form3 and to present data as read-only and Form2 should open Form3 to present editable data. // Form3's constructor accepts a boolean to indicate whether or not data may be edited public Form3(bool AllowEditing){ InitializeComponent(); // Initialization regarding editability goes here } Now someone else, or you a year down the road, can understand what the meaning of the constructor's parameter is. Form1 and Form2 can open Form3 as follows: //Within Form1 public void ShowForm3(){ // Show Form3 as readonly. Form3 displayForm = new Form3(false); displayForm.ShowDialog(); } // Within Form2 public void ShowForm3(){ // Show Form3 and allow editing. Form3 displayForm = new Form3(true); displayForm.ShowDialog(); } Another advantage beyond readability is reusability. If you need to show Form3 from somewhere else (a UserControl or a DLL that doesn't own any forms) you don't need to pass a Form to the constructor, whereas using the other method the constructor expects an instance of Form1 or Form2. I'm not telling you to change the code you've already written, just something to consider next time you have to make a design choice.

I don't know about VB Express, but with C# Express any controls and components you declare in a project automatically appears at the very top of the toolbox (I know that this wasn't the case in .Net 2003). As far as your comment about removing design-relate properties, if by design-related properties you mean those regarding the form's layout then I personally agree whole-heartedly, but I suppose that Microsoft had their reasons. Multi-line textboxes are never autosized and single-line textboxes that are oversized or undersized often simply don't look right with extra white below the text or hanging letters clipped on the bottom. I guess they deemed the property irrelevant. I, however, sometimes like to nudge things a pixel or two to make the elements of the UI line up.

There is no "work around." This is not a bug, it is by design. (Do I sound like I work at Microsoft?) Font objects are "Immutable," i.e. you can not modify them once created, just like strings (notice that all string functions return a new string object). In order to change the size or style of a font you must create a new System.Drawing.Font object. Fortunately Microsoft made made a constructor that accepts a prototype font and allows you to specify a style, like so: ' Make this control's font bold, not italic, not underlined, and not strikethru: Me.Font = New Font(this.Font, FontStyle.Bold) If you need to change size too then you need to use a normal constructor. ' Make this control's font size 16 bold italic Me.Font = New Font(Me.Font.FontFamily, 16, FontStyle.Bold or FontStyle.Italic)

I've never noticed before, but now that you mention it, AutoSize is MIA from the property window. I guess Microsoft decided to reduce clutter in the property window and AutoSize was one of the ones to go. I suppose you will have to live with the fact that you have to set the property in code. If it is horribly inconvinient for you, you can subclass the TextBox class and create a new AutoSize property that will be visible in the property window. In fact, here it is for you: 'Textbox Plus AutoSize property in the property grid Public Class TextBoxPlus Inherits TextBox <System.ComponentModel.Browsable(True)> _ Public Shadows Property AutoSize() As Boolean Get Return MyBase.AutoSize End Get Set(ByVal value As Boolean) MyBase.AutoSize = value End Set End Property End Class

I would recommend PlausiblyDamp's method because it stores the entire image file into the array, including the pixel format and dimensions. The first example only extracts raw pixel data to the array, which is not enough to reproduce the image later.

How does it bother your program? When you format dates you can specify a format string. If you need the string in a specific format then it is your responsibility to specify that format in the DateTime.ToString method. If you need to parse dates from a specific format, you should be using the DateTime.ParseExact method and specifying the format. You can't expect or depend on a default format. A program should never change that kind of setting on a user (unless that program is specifically intended for that purpose). Just because another program does something that it shouldn't doesn't mean that your program should too.

Take another look at the code posted by Wraith: string foo = "C:\SomeFolder\SomeDoc.txt"; if (Path.IsRooted(foo)) foo=Path.GetFileName(foo); // now foo = "SomeDoc.txt" The IsRooted method determines if the specified filename is absolute (i.e. "rooted" means that a drive name is specified). The GetFileName method gets the name of the file without the preceeing folder path. Note that this is not the same as a relative path, though. For instance, if a file is loaded from "designTimePath\Data\SomeFile.ext" at design time, the relative path at runtime would be "runTimePath\Data\SomeFile.ext", but your code, as it is written, will store the filename simply as "SomeFile.ext". The code you posted confuses me... (sans comments) Set(ByVal Value AsString) If System.Text.RegularExpressions.Regex.IsMatch(Value, "^[a-zA-Z]:\.*..*") Then FileName = System.IO.Path.GetFileName(Value) Else FileName = System.Windows.Forms.Application.StartupPath + "" + Value EndIf It looks like you are trying to determine whether the property is set a runtime or design time based on the format of the filename. This is hardly foolproof. If a relative filename is specified it is stored as absolute, and if an absolute filename is specified it is stored as relative. Think about this: if you use a dialog to get a filename it will be absolute, which will cause it to be serialized as a relative filename. Next time the designer is open the property will be initialized with this relative filename, which will cause it to be stored and serialized as absolute. It will flip-flop like this each time the component is opened in the designer, and exceptions become inevitable. Why not have the file name always stored internally with a relative filename and construct the full absolute filename when the filename is retrieved, i.e.: Dim _Filename As String 'Gets/sets the filename. This property always internally stores the filename in a relative manner. Public Property Filename As String Get Return _Filename End Get Set(value As String) 'If filename is absolute the remove the path and keep only the filename If System.IO.Path.IsRooted(value) Then _ value = System.IO.Path.GetFileName(value) 'Now we will never store a rooted filename here _Filename = value End Set End Property 'Gets the absolute path to the filename. Public ReadOnly Property FullFilename As String Get Return System.IO.Path.Combine(Application.StartupPath, _Filename) End Get End Property Of course that probably does not suit your needs exactly, and may need to be modified. For instance, you might want to store both the full filename for design-time use and the relative filename for run-time use. It won't hurt to serialize the extra data, and you can be sure that you maintain exactly the right path to the file at design-time (provided that the project is not moved from computer to computer). BTW, for tips on having your component differentiate from design-time and runtime (i.e. retrieving the correct filename if you use the technique I described above), look in the Code Library for a recent post by me on the topic.

A common method to implement plug-ins is to have a main application EXE, a separate DLL that defines the plug-in interface (and possibly a host interface to allow the plug-in to invoke methods on the host environment), and both the EXE and plug-ins should reference the DLL, which references neither. This eliminates circular dependencies and provides an API for programmers to write plug-ins without a dependency on the actual EXE. This is not necessary, though. It is acceptable for the main EXE to define the plug-in interface, and the host interface if there is one. The plug-in can reference the EXE to obtain the API (i.e. interfaces). This is the important part, which Gill Bates pointed out: The main EXE does not need to, and further more, should not, reference the plug-in DLL. Rather, the main EXE should use reflection to load the plug-in DLL and search for classes that implement the plug-in interface. You can think of this as a sort of late-bound dependency to circumvent circular dependency issues, although it introduces a great deal more flexibility than just that. I mentioned a "host interface" twice, so I will explain exactly what I mean by that now. A plug-in system usually defines an interface for the plug-in. Something like IPlugIn. You can also declare a host interface that the hosting application should provide to the plug-in, for example, IPlugInHost. IPlugIn should expose a property that accepts an IPlugInHost and when the host application instantiates the plug-in class it should assign an instance of an IPlugInHost to the said property. This provides the plug-in with a method to make callbacks to the host, eliminating the need for the use of events. But I highly recommend that you carefully consider whether or not you need either a host interface or events. Generally all the feedback you need to get from a plug-in can be obtained by return values from function calls into the plug-in. Just some notes on other posts: internal in C# is the same as Friend in VB. As was said, VB6 projects could not reference EXEs, only DLLs, and the same applies to .Net 1.x, but in .Net 2.0 EXEs and DLLs can both reference EXEs and DLLs. This makes things easier in some situations. For example, if you provided a feature-rich file compression application and wanted its functions to be available through its normal GUI but also available in code for other programmers you no longer need to put the good stuff in a DLL and distribute two files. In .Net 2.0 you can distribute it all as a single file, declaring what you want to be accessible to other coders as public.