snarfblam

The ""c notation actually represents a character constant, whereas cchar is a conversion expression. I am pretty sure that, when possible, cchar will be simplified to a character constant, just as the Char() function is often simplified to strings at compile time. The functions are available at runtime, too, for dynamic conversions, but the ""c notation is actually simpler and a more accurate and reliable representation of a character for the compiler. 'The compiler is smart enough to know when certain expressions can be simplified ' to a constant. Dim SomeChar As Char = CChar("B") ' Compiles to the same as Dim SomeChar As Char = "B"c ' There are situations where cChar can't be simplified to a character constant. Public Function AsChar(string letter) As Char ' CChar, at face-value, is a conversion function. When the expression ' being converted can vary, like a parameter to a function... return CChar(letter) ' it can't be simplified. End Function

Have you tried setting the StartupPosition property to Manual?

No limit, but wouldn't that be awefully time consuming to design in the IDE? At this point you might simply want to store the data for the buttons in an XML or TXT file and at runtime read the data and create the buttons and attach handlers dynamically. (This would also allow you to expand the options later without re-compiling the EXE.) If you prefer, though, there is nothing stopping you from creating as many tool strip buttons at design time as you like and using the same handler.

You can specify multiple controls or events in the Handles clause, like so: Private Sub AnyToolStripMenuItem_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) _ [i] Handles RelocatableModularBuildingsToolStripMenuItem.Click, SomeOtherToolStripItem.Click, YetAnotherToolStripItem.Click, OneMoreToolStripItem.Click[/i] WebSearch = DirectCast(sender, ToolStripItem).Text End Sub

Can you use the Thread.Join method (which blocks until the specified thread completes)?

I think that Application.Exit is generally looked down upon. Resorting to it is generally a sign that you need to re-evaluate your design. Mutant is right, closing the main form is usually the way that an application is closed. Perhaps the main form should handle the Closing event of each other form and determine for itself when it should be closed. Or perhaps when a form is closed it should notify the main form. Application.Exit will probably suffice, but if the program were to become larger and more complex or you write another application that is larger and more complex it can become a problem that exactly which class is controlling the application in what manner is unclear.

Sorry its C#, but this appearently equivalent code worked just fine for me: public partial class Form1:Form { public Form1() { InitializeComponent(); } private void Form1_Load(object sender, EventArgs e) { MethodInfo Foofo = this.GetType().GetMethod( "FOO", BindingFlags.Public | BindingFlags.IgnoreCase | BindingFlags.Instance, Type.DefaultBinder, new Type[] { }, null); Foofo.Invoke(this, null); } public void foo() { MessageBox.Show("Bar."); } } Note that I use the same binding flags and the method is declared as "foo" but searched for as "FOO".

As a first step, I would declare certain members with the internal keyword in C# and the Friend keyword in VB, which declares something as visible only to the declaring assembly (i.e. the plug-in can't access them, but neither can any other external libraries if they need to). In C# 2 (and maybe VB8, I'm not sure) you can declare different property accessors with different visibility, like so. public int SomeIntProperty{ get{ return someBackingField; } internal set{ someBackingField = value; } } Secondly, this is a matter of design. The objects exposed to the plug-in should only generally expose that which the object needs to manipulate. If the plug-in is given objects which in can manipulate in a malicious way you may want to re-examine your design and object model. For instance, let's look at an application that supports plug-ins which may need to be able to manipulate a form. I would hesitate to pass the form directly to the plug-in, because the plug-in now has full control over the form and all the controls that it contains. One solution would be to have the form implement an interface that would be shared with the plug-in that only defines methods necessary for the plug-in, and pass any forms to the plug-in as an instance of that interface. This has the drawback that the objects can still be cast back to a Form, but it does explicity let plug-in coders know what they should and shouldn't do. Another solution would be to create a class to act as a proxy for the form, and only provide those methods that are needed for the plug-in. Since the plug-in can't get direct access to the form, it can only do what you specifically allow it to do. Of course, if the plug-in is running with full trust, no matter what you do someone can use reflection to find its way back to an important Form or something else that it can manipulate and cause problems, so you might want to check whether or not there is a way to load DLLs with partial trust.

[color=blue]if[/color] (sender [color=blue]is[/color] StatusBarPanel) { [color=red]becomes...[/color] [color=blue]If Typeof[/color] sender [color=blue]Is[/color] StatusBarPanel [color=blue]Then[/color] MessageBox.Show( ((StatusBarPanel)sender).Name + " was clicked..."); [color=red]becomes...[/color] MessageBox.Show( [color=blue]DirectCast[/color](sender, StatusBarPanel).Name + "was clicked...") } [color=red]becomes...[/color] [color=blue]End If[/color] Once you wrap your head around the curly braces C# and VB are practically the same thing.

In C# that would be spelled: string TmpTxt = "O'Niel"; TmpTxt = TmpTxt.Replace('\'', "\+char(39)+'"); // TmpTxt now equals: O'+char(39)+'Niel Ready for some info? C# specifies character constants by placing a character between single quotes, i.e. apostrophes ('). For example, the X character would be 'X'. Then question mark character would be '?'. Furthermore, certain characters require escape sequences to be represented. For example, an apostrophe can't be included directly into a character literal (just as a double quote can't be directly included in a string literal), so we use the escape sequence \', where the backslash modifies how the following character is interpreted. To do character constants based on the numerical value of the character you can use a Unicode escape (For example, Chr(39) in VB is the same as '\u0027' in C# [note that 39 in hexadecimal is 27]). To convert an integer value to its corresponding character at runtime, use the System.Convert.ToChar function. If you want a more thorough (or clearer) explanation, check out MSDN�s documentation on C# string literals.

Yeah, I figured that out after I posted my reply because when I posted my reply I saw your fixed post. So I deleted my reply. So yeah...

Maybe... Public Class Form1 Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load 'Call hioh with a newly created array... hioh(New String() {"ioj", "OIJ"}) 'Call that other method with arrays mnkxsjmksdx(New String() {"fe", "htr", "fdsa"}, New String() {"hgt", "htr"} ) End Sub 'Method that accepts an array Private Sub hioh(ByVal f() As String) MessageBox.Show("Recieved array with " & f.Length.ToString() & " elements.") End Sub Private Sub mnkxsjmksdx(ByVal a() As String, ByVal b() As String) End Sub End Class By the way, I like the mash-your-face-into-the-keyboard naming convention.

Not knowing anything at all about Office interop, if I had to guess I would say that one approach would be to extract the resource to a file on the disk and open it from there. If the Word.Application can accept a stream, it should also be possible to create a stream to read the resource and skip the intermediate step of using the hard drive. But that's all coming from someone who doesn't know anything at all about Office interop.

Static in C# == Shared in VB. You can use type initializers ("Shared Sub New") for your classes in your class library to initialize the class library. For any class that needs to have shared members initialized, declare a sub new that is marked as Shared. The only limitation when using this technique is that the type initializers ("Shared Sub News") can not have circular dependencies (i.e. ClassA's type initializer can't in any way involve ClassB if ClassB's type initializer involves ClassA). So, to answer the original question, You would declare a Shared Sub New in the class that contains the list and initialize the list from that sub. Or, you could use Gill Bates' lazy initialization technique, but I personally wouldn't put fourth the effort of implementing lazy initialization unless there is a decent chance that an object won't be used.

The best way to get something done always depends on the details. When manipulating strings, it is very oftem more efficient to use a StringBuilder because it does not require a new string to be created for every single step of the process. For very simple operations, though, it may be best to not bother. Using the System.String constructor in this case involves the creation of only one object, whereas the use of the string builder always involves the creation of the string builder, an underlying char array, and finally the resulting string, and more often than not, multiple char arrays need to be allocated as the size of the string increases. Knowing the details of the classes you are using (and, almost as important, knowing what is going on under the hood) allows you to make decisions like this simply and with confidence, letting you do what you decide makes the most sense instead of what others have recommended (not that there is every anything wrong with listening to the recommendation of an advanced programmer, but rather this is the distinction between a programmer and an advanced programmer). As for my so-percieved blunt sarcasm, I seldom hand out sarcastic comments and when I do, I do so with good humor. If you took it the wrong way, sorry, but unless one gives me good reason beforehand, I'd never say something with the intent to disparage or harass another. Also, mandelbrot is right about obfuscating the password. The less that is known about it, the better. But, for that matter, why bother passing the asterices in the URL at all? If you aren't going to pass the data then why pass anything? And, one last thing, the 'c' after the text between the quotes indicates that the text is a System.Char instead of a System.String.

Suppose an object X subscribes to an event of object Y. The following chart shows how the references affect garbage collection. The important thing to understand is how events are stored. When X handles an event from Y, X does not store a reference to the event in Y, but rather Y stores a reference to the handler in X. This means that when X handles events from Y we don't have references from X to Y, but exactly the opposite. After looking at the chart, one might think something like, "What if a .Net method is used as a callback for Windows or an unmanaged DLL? Then wouldn't the object still be active even though no .Net objects reference it? Couldn't it raise events even though it is eligible for garbage collection?" The answer is that when we pass a delegate to an unmanaged DLL, the .Net runtime sets up a thunk to marshal data between managed and unmanaged code, and this thunk maintains a reference to the object in question, "rooting" it and preventing it from being garbage collected.

There is a standard in .Net where every event has two parameters: a sender declared as an object and arguments declared as EventArgs or a deriving class. If you look at EventArgs in the .Net Reflector you will see that there really is nothing to it. There is a point to it, however. First of all, it is simpler when all events follow the convention. Secondly, it allows you to use contra-variance. A single event handler can take advantage of contra-variance and handle any event that conforms to this standard, but only because every event passes an EventArgs or derived class. Public Sub UniversalEventHandler(sender As Object, e As EventArgs) MessageBox.Show("Message recieved from " & sender.ToString() & " with " & e.GetType().ToString() & ".") End Sub Public Sub Demonstrate() 'See how having an EventArgs makes events more flexible, even though 'The EventArgs might not carry any data? AddHandler SomeButton.Click, AddressOf UniversalEventHandler AddHandler SomePanel.MouseMove, AddressOf UniversalEventHandler AddHandler SomeTreeView.BeforeLabelEdit, AddressOf UniversalEventHandler End Sub This is seldom useful, but it is really beside the point anyways. The big picture is that all events should follow a standard.

In other words, the type used should reflect the intended use. If you are using an IList, you shouldn't need to know its System.Type, all you need to know is that it implements a list service. Interfaces are there so you can kinda forget about types. If you need to test the System.Type of an object, you can use the TypeOf...Is... clause: Dim List1 As IList = New List(of Integer) If(TypeOf List1 Is List(of Integer)) Then _ MessageBox.Show("List1 is a list of integers.") or you can cast to a System.Object to treat the item as an object. As to Implicit/Explicit interface implementations, VB has no direct analogy. In fact, VB is much, much more flexible in this manner. VB can implemenet each member (using "C# terminology") "implicitly" (declare the method as public), "explicitly" (declare the method as private) or implement the member using a different name than the interface's declared name for that method.

Building on Cags' answer, a quick recommendation. If you are adding text to the ListBox from one place and only one place, I would do exactly as Cags said: code the logic in directly after the call to ListBox.Items.Add. If you might be adding text from multiple locations, do either one of the following: (1)Define a method that will always be used to add text to the ListBox. This method will insert the item into the ListBox and do any network notification of the message. (2)Subclass the ListBox to create a network message box. Hide, override, or shadow the Items property since it probably won't be necessary to access externally (the managing of items should be done internally) and create a public method to add a message which will also broadcast this message over the network to other network message boxes. Either way you are creating a function that all text to displayed should be channeled through, allowing you to intercept messages instead of catching them with events.

If you really want to do it properly, I recommend the System.String constructor... 'Lets say twelve chars, just for example Dim AsterixCount As Integer = 12 Dim Asterixeses As New String("*"c, AsterixCount) 'Asterixeses = "************" 'Or do it all in one line Dim StringWithAsterixeses As String = "This is a string with some " & New String("*"c, 7) & " asterixeses." 'StringWithAsterixeses = "This is a string with some ******* asterixeses."

That last parameter (the true)... My.Computer.FileSystem.WriteAllText("c:\Temp\stmanplt.scr", TextBox1.Text, True) is the Append parameter. If you append text to a file you will add the text onto what is already there. Is it possible that the extraneous characters were already in the file? Another possibility (I'm not sure, I've never used the "My" feature) is that the extraneous characters are a length prefix (i.e. data written to the file to specify how long a string is, and not meant to be viewed as text. If this is not the case, a simple solution would be to use the more .Net-friendly (i.e. compatible with all .Net languages) and proven approach of using a StreamWriter: 'This method will write (or append) the specified text to a text file Public Shared Sub WriteToFile(file As String, text As String, append As Boolean) { Dim writer As StreamWriter = new StreamWriter(file, append) writer.Write(text) writer.Close() End Sub

Given that little information it is impossible to say. If you have a main menu and that menu is visible and it has subitems that have text and those subitems are visible the menu should be visible. Is there any owner drawing going on? What happens if you copy the menu onto a new form, or remove the menu and add it back?

How are you saving the text?

Well, if it is an old app that you are converting then that would be a fair use of the legacy control. Microsoft deprecated it because the FileListBox is an old way of doing things, generally used from Windows 3 back to dos, though it can occasionally be seen in apps for Windows 95 and later, it is almost never used in professional applications today. The fact is that it's functionality is very simple to reproduce: Get a DirectoryInfo object for the folder you want to list files from, use that to get a list of files and loop through them, adding them to a ListBox. And since it is seldom used anymore and tends to be much more difficult to use than an open file dialog I personally think that deprecation is appropriate. Regardless, there should be a method to refresh the contents of the control.

If you are certain that you are disposing all of the IDisposable objects that you aquire/create then I would say that the third party components should be your biggest suspect. Could you be more specific about what these thiry party components/DLLs do?