snarfblam

The framework would have to be installed on the computer running the EXE, not on the network. The dlls could probably be installed on the network. I believe, however, that if you run a .Net app over a network the framework restricts the security (file i/o, registry, etc.).

What do you want to do with them at design time? If you use an image as a property on a control then the code to do this is generated for you. If not, then I don't understand what could be done for you at design time. Perhaps an ImageList component would make your life easier. This will embed the images for you and you can pull them up at run-time by index with a single line of code. If I am making an app with a lot of embedded images, I always make a function that accepts the image's pre-compile filename and loads the image for me. [Vb] Public Shared Function GetEmbeddedImage(Name As String) As Image\ Dim Assm As Assembly = Assembly.GetExecutingAssembly() Dim AssmName As String = Assm.GetName().Name Dim Stream As Stream = Assm.GetManifestResourceStream(AssmName & "." & Name); Return Image.FromStream(Stream) End Sub [/code]

You might want to read up in operator overloading. It isn't supported in Vb.Net 2003, but you can explicitly call the function that an operator is mapped to. A cast would be op_Explicit, Addtion would be op_Addition, etc.

Of course, you probably want to verify that either the e-mail of fax number is in a valid format. I would just check for and "@" followed by a "." and invalid characters for the e-mail and check that a phone number only contains digits (or letters if you want to allow them), parentheses, and dashes and spaces (and periods if you want to allow a format like "555.555.5555").

How about constructing the path name yourself. Private Function AppDataPath() As String 'Keep only the first two numbers in the version Dim Version As String = Application.ProductVersion & "." Dim VersionLength As Integer = Version.IndexOf("."c) + 1 VersionLength += Version.Substring(Version.IndexOf("."c) + 1).IndexOf("."c) Version = Version.Substring(0, VersionLength) 'Create the application data folder using the formula specified in 'MSDN (CommonAppData\Company Name\Product Name\Version) Dim MyPath As String = Environment.GetFolderPath _ (Environment.SpecialFolder.CommonApplicationData) MyPath = IO.Path.Combine(MyPath, Application.CompanyName) MyPath = IO.Path.Combine(MyPath, Application.ProductName) MyPath = IO.Path.Combine(MyPath, Version) Return MyPath End Function

I don't plan on writing any apps in IL or anything like that. But a small DLL? Maybe. Why would I wanna do a thing like that? To write highly optimized code. I know that the usual response to this is "Do you really think that you can hand optimize better than the VB/C#/C++ optimizing compiler and JIT?" And generally, the answer is no. There are some ways, however, that you are restricted with VB and C# (less so as far as C# is concerned). I program primarily in VB and there are lots of things I notice that I don't like. The fact that there is no way to directly access certain memory (like bitmap data) without using a hacked out workaround that is still not as optimized as I like, the fact that when I cast in VB the compiler likes to throw in unnecessary calls to Microsoft.VisualBasic, the fact that integer overflow checks are all or none in an entire project, etc. Being able to program in IL gives you much more control. I can write slightly irregular loops and still optimize out the bounds check on array access. Most of all, I can micro-optimize to my heart's content. Maybe I have OCD but I would like to have the ability to get a little closer to the CLR in the same manner that an assembly programmer wants to get closer to the hardware.

Does anyone have information on writing and compiling IL? I found a website with an entire IL IDE, but the download links all lead to a 404 Not Found page.

You are looking for help at the wrong place. The application that a particular extention opens with depends on the computer that you are using. This is a per-computer setting. Your JPegs might open with Windows Picture and Fax Viewer, while mine open with ImageReady.

Do a debugger step-through, and see what happens. If you give us more info we can give you more help.

The distribution is a variable. A Dell Windows distribution may come with the .Net Framework. Others may not. It may also depend on the date of the distribution. Just keep in mind that having Windows Xp does not guaruntee the presence of the .Net framework.

ShowDialog will pause execution of the calling sub until the form is closed or hidden. Is this the behavior that you are observing?

The functions in the Microsoft.VisualBasic namespace were actually written in .Net (probably either C# or managed C++). You are correct about the example you provided being optimized out, but such optimizations only pertain to constants that can be evaluated at compile time. 'VB Const Test As Char = ChrW(&H11) 'IL .field public static literal char Test = char('\x11') As I've said, most VB functions are wrappers for .Net functions. Let's take a look at the decompiled Len() Function [Vb] Public Shared Function Len(ByVal Expression As String) As Integer If (Expression Is Nothing) Then Return 0 End If Return Expression.Length End Function [/code] When you use Len(), Len() does a safety check and then returns String.Length for you. Granted, Microsoft tried to make these functions idiot proof by checking for null references, but otherwise, this function is nothing more than a wrapper. As far as coversion functions like CInt, CDbl, etc. These are a different story. If you are doing a conversion between numeric types then these can be inlined. This isn't necessarily any better than using .Net conversion classes. 'This: Dim X As Intger Dim Y As Double X = Cint(Y) 'Is compiled as this Dim X As Integer Dim Y As Double X = CType(Math.Round(X), Integer) 'It does nothing more for you than save you some typing. And Calling CInt/CDbl/etc. on a string calls a Microsoft.VisualBasic function that in turn calls Integer.Parse/Double.Parse/etc. Microsoft.VisualBasic tends to use very unstraightforward methods and seldom offers any advantage over a non-Visual Basic method. Your best bet is to understand what is going on under the hood with it so that you know when to use Visual Basic function and when not to. I would say that VB functions will generally run slower, but the difference will also generally be negligible, either way.

Sorry, I guess I just like to split hairs. I wouldn't say that Convert really has to figure out that you are using a string. The compiler chooses the correct overload at compile time, so that essentially Convert.ToBoolean(String) is the same as Boolean.Parse(String). There might be differences, for instance, localization, between the Parse methods and the Convert class. That, I'm not sure about.

This is not a bug specific to .Net, either. This is floating point math with computers, period. You will sometimes find your results off by one or two in the least signifigant digit. Sometimes it makes your numbers look ugly (69.99999999 instead of 70) but in mathematical terms the roundoff error isn't particularly signifigant. You might find that your results will be better if you use the Decimal data type (and you might not). You might also want to use one of the Double.ToString to format your number to round off so something close will appear correctly (99.99999 will round to 100.00).

Just a note. Windows Xp does not come with the .Net framework. I don't know if sp1 or sp2 does.

Its not quite that simple. Just as you need the VB6 runtime files installed on the destination machine to run a VB6 app, you need the .Net runtime files (the ".Net Framework") installed on the destination machine to run a .Net app. The .Net Framework can be downloaded from Microsoft.com, through Windows Update, or distributed either by itself beside your app (read the licesnce to make sure that this is allowed!) or as part of a deployment package (I know that this is allowed) created with .Net. I would recommend telling your end user to download it at http://www.microsoft.com/downloads/details.aspx?FamilyID=262d25e3-f589-4842-8157-034d1e7cf3a3&DisplayLang=en if they don't have it, and let them know that they are in for a wait. It is not a small download.

I believe that the code samples linked to give you exactly that functionality. Take a closer look.

I don't know what the code is supposed to do but it looks like your difficulty lies in converting from an IntPtr to a GCHandle. Try this: Private m_context As IntPtr Public ReadOnly Property UserContext() As Object Get Return GCHandle.op_Explicit(m_context).Target End Get End Property

I think that you are generally right about staying away from Microsoft.VisualBasic for exactly the reasons you mentioned. I personally exclude it from every project I make because the majority of functions and classes in Microsoft.VisualBasic are essentially nothing more than wrappers for the equivalent .Net classes/functions and only exist for the sake of being able to access the features using the old VB6 names. Others would disagree. For instance, some Visual Basic functions perform certain common sense checks (IsArray first checks if the object is Nothing before returning TypeOf(Object) Is System.Array, and the Len() function similarly checks first to see if the string passed is Nothing before returning String.Length()). Microsoft's take is that Microsoft.VisualBasic is part of the VisualBasic language and is okay to use. As far as Microsoft.VisualBasic.ControlChars specifically, I wouldn't worry much. For those who don't program in VB, ControlChars is self-explanatory and easy enough to convert.

The c indicates that the value is a Char constant. A Char is a value type that holds a single character (sort of like a 1-character fixed length string). Just like the "r" in 1.0r indicates that a value is a double, the "c" in "."c indicates that the value is a Char (as opposed to a string).

You might want to take a look at this: Api Viewer. It contains struct, constant, and function definitions in a variety of languages. I personally don't have much trouble using the Windows API, and the conversion from VB6 to VB.Net (in terms of the API) wasn't particularly difficult for me. Generally the only modifications you need to make are changing Longs to either Integers or IntPtrs. (.Net represents handles and pointers with the IntPtr struct). I got this from API Viewer. Again, I would change hwnd from Int32 to IntPtr so that you could use the Control.Handle property to get its hWnd (which is of type IntPtr). The return is an Int32, but it is easy enough to compare it to zero to see if the return is true or false. Declare Function MoveWindow Lib "user32.dll" ( _ ByVal hwnd As Int32, _ ByVal x As Int32, _ ByVal y As Int32, _ ByVal nWidth As Int32, _ ByVal nHeight As Int32, _ ByVal bRepaint As Int32) As Int32

TabControl.SelectedIndex As Integer or TabControl.SelectedTab As Tabpage

There are two methods to doing this. The one you would use depends on your needs. You can invoke a method dynamically through reflection in a manner such as that demonstrated by bri, or you can compile the code on the fly. Unfortunately, there is no function to simply execute a string as there was (hidden away) in VB6. I believe that there is actually a tutorial of compiling code on the fly in the Tutors corner (although the topic is something like "Scripting your app"), however, this involves creating an entire assembly in memory and might be a bit much for what you want to do.

I know that this is not what you were asking and I'm not trying to rag on your coding, but I just want to point this out, in case you aren't aware. Note the underlined code Private Sub hoverDiente(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles d1.MouseHover, d2.MouseHover [u][b]sender = CType(sender, PictureBox)[/b][/u] Dim tempStr As String = sender.name tempStr.Replace("d", "") MsgBox(Me.path) sender.Image = New Bitmap(Me.path + "\\path\\" + tempStr + ".jpg") End Sub This line casts "sender" to type PictureBox, and stores the reference back into the "sender" variable, whose type is Object, essentially uncasting to object and forcing you to use late binding when you access sender.Image. This would be a better approach. 'At the top of the file Option Strict On 'Hover image code Private Sub hoverDiente(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles d1.MouseHover, d2.MouseHover [u][b]Dim picSender As PictureBox = CType(sender, PictureBox)[/b][/u] Dim tempStr As String = picSender.name tempStr.Replace("d", "") MsgBox(Me.path) picSender.Image = New Bitmap(Me.path + "\\path\\" + tempStr + ".jpg") End Sub Another note, this one related to the issue at hand: when constructing file names, I recommend using the IO.Path class to avoid issues with missing/doubled backslashes. 'At the top of the file Option Strict On 'Hover image code Private Sub hoverDiente(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles d1.MouseHover, d2.MouseHover Dim picSender As PictureBox = CType(sender, PictureBox) Dim tempStr As String = picSender.name tempStr.Replace("d", "") MsgBox(Me.path) [b][u]picSender.Image = New Bitmap(IO.Path.Combine(_ Me.path & "\\path\\" & tempStr & ".jpg")[/u][/b] End Sub

I have never had a problem with EnableVisualStyles and exceptions, and to resolve any confusion: you only need either a manifest or EnableVisualStyles(), not both. Here is a third solution involving manifests: The manifest can be embedded within the exe.