snarfblam

Now that we've thoroughly explained Diesel's frustration, is there any particular part of the conversion that is troubling you? Or are all of those wacky curly braces just gibberish to you?

Looking over your structure definition again, I see two problems. First of all, you are replacing a pointer to a Word (Word is a numeric type) with a string, and you are replacing a pointer to a float with a float (Single). Secondly, seeing as the C++ union actually contains two pointers of different types, I don't think you actually need a union. VB only supports one kind of pointer, the IntPtr. I don't know whether you need to access the data that this pointer points to. Again, I don't know if it will help, but you can try modifying your code as follows: Imports System.Runtime.InteropServices <StructLayout(LayoutKind.Sequential)> _ Public Structure BufferScaleType Public factor As Single Public offset As Single <MarshalAs(UnmanagedType.ByValTStr, SizeConst:=16)> _ Public description As String <MarshalAs(UnmanagedType.ByValTStr, SizeConst:=16)> _ Public unit As String End Structure <StructLayout(LayoutKind.Sequential)> _ Public Structure BufferType Public isFloat As Integer Public nx, ny, nz, nf As Integer Public totalLines As Integer Public vectorGrid As Integer Public image_sub_type As Integer [b][i][color="Blue"]Public floatOrShortPointer As IntPtr[/color][/i][/b] [color="SeaGreen"]// This might point to an array[/color] Public scalex As BufferScaleType Public scaley As BufferScaleType Public scalei As BufferScaleType End Structure

Is the error due to converting a managed object to a COM variant, or vice-versa? DBNull.Value is not a null value, it is an object that represents a null database value. Visual Basic represents null with the keyword "Nothing", so try this: Public Declare Function ReadIMX Lib "ReadIMX.dll" (ByVal filename As String, ByRef btype As BufferType, ByRef attributelist As Object) As Integer Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click Dim filename As String = "D:\Daten\Messungen\Test\429mbarAr_7_5kHz_740Vpp_696_64nm\B0001.IMG" Dim buftype As New BufferType Dim A As Integer = ReadIMX(filename, buftype, [color="Blue"]Nothing[/color]) End Sub That might help. It's hard to say. Things get tricky with P/Invoke when you throw in pointers and pointers to pointers and unions.

I found a mediocre solution on CodeProject. As far as I can see, the biggest problem is that there is no way to obtain the bounding rectangle for each tab unless you enable owner drawing, which means you lose visual styles. [Edit]Looking around Google, there seem to be plenty of free custom-made tab controls that support close buttons, but you still lose the native OS appearance.[/edit]

Unfortunately, C# has no built-in support for [Flags] enumerations. In other words, no automatic value assignment, no direct access to individual flags in composite values, etc.. I prefer to write hex literals for the constants, but your bit-shifting solution is probably your best bet.

The syntax for a for-each statement is: For Each variable As type in Collection ' Code Next You are specifying Items as the variable type of i. Try changing Items to Object. If your listbox will contain only one type of object, you can specify a more specific type.

The first thing I see wrong is that you are using the Form's paint event to handle painting for the panel. Overriding the Form1.OnPaint method is equivalent to handling the Form's Paint event, but you don't want to draw on the form, you want to draw on the panel. The code in your OnPaint method should be moved to Panel1_Paint. And just a note: whenever you override any OnSomething method, you need to call the overridden (base) method. In other words, you would need to call MyBase.OnPaint(e) in the OnPaint method. Otherwise some event handlers might not be called. As for your problem of getting things to be redrawn, the important concept here is invalidation. The Paint event (or OnPaint method) is responsible for doing the drawing, but it needs to be told when to draw. This is done by invalidation. You want to call the Panel1.Invalidate method to tell it that part of the control is invalid. For example, suppose the panel were covered by another window, and then that window is dragged out of the way. The panel now needs to be redrawn. It has graphical leftovers on it from the window that was dragged away, and is therefore invalid. In that case, Windows will automatically invalidate your panel for you. In other words, "invalidating" a control simply means informing it that it needs to be redrawn. If your program's data changes, and that change needs to be shown on the control, you need to invalidate the panel yourself, by calling Panel1.Invalidate.

There is both a user-specific and an all-users folder, each called "Application Data", which would probably be an appropriate location to store program settings. Generally, the program files folder should be considered read-only because a limited user may not be able to write to this folder, especially the all-users program files folder. (This certainly applies to XP.) As far as the original question, the registry versus settings file issue is an ongoing debate, and each solution has its strengths and weaknesses. The registry is pretty simple and convenient, but if a user wants to migrate the settings to another computer, he would need to find the key(s) and create a registry patch, probably not worth the effort. If the settings are written in the same folder as the executable, then the user can bring the whole package around with him on a disk, but then you have to consider that whole pesky "writing to program files" thing. And if you write the settings to the application data then you've decoupled the executable and the data. For all the benefits and costs that come with that you find yourself in a situation very similar to that with the registry. If you use a file instead of the registry, at least you can ditch the non-standard Win32 DLLs, if you care about such things. (How many of your users are running Mono?) Any solution is a mixed bag so I guess it's mostly a matter of preference. I used to use the registry, but now I write a settings file, preferably in the user's application data folder.

It may be that there is code running somewhere else before your Form_Load event. It could be in the InitializeConstructor function created by the form's designer, or in static class or module initialization code, or in your Sub Main. You don't think about it, but there's alot of code that is run before you get to your "entry point." One thing that can be real easy to overlook is field initializers. You could be calling all sorts of constructors to initialize variables long before you ever get to Form_Load.

Re: Using a standard DLL The process of interoperating with a non-COM DLL is formally called P/Invoke (platform invoke). Like MrPaul said, needing documentation is a fact of life working with standard DLLs. If you do get that documentation, Microsoft has a comprehensive tutorial on P/Invoke.

Are you looking for anti-aliasing of the region (i.e. are you looking to have the edges of the control alpha-blended)? If so, DotNet doesn't have built-in support for such a feature. I don't know what kind of control you are dealing with, but if it is a custom control, you may be able to simulate the effect by doing custom rendering with an alpha-blended image instead of using regions.

Unless you are doing at least thousands upon thousands of string comparisions, there really is no legitimate concern about performance. It is good to know which method is faster, but the real reason that I would go with option # 1 is because it is more straight-forward and self-explanitory, even if it is longer. In this particular instance, I think either solution would be perfectly adequate, but in terms of general coding style it is best to avoid the potentially cryptic and stick with code that spells out what it is doing.

lblToChange.Font = [color="Blue"]New [/color]Font(lblToChange.Font, [i]FontStyle.Italic [color="Blue"]Or [/color]FontStyle.Bold[/i])

Color.ToARGB() should return a 32-bit integer composite value that would be the VB6 equivalent, although the alpha component may have to be filtered out.

If you want to see if a particular character is alphanumeric you can use the Char.IsLetterOrDigit().

That is exactly your problem, and there is no easy workaround. Like I said, you could try using "layered windows" to achieve a real alpha-blended form, and it will work perfectly, just not on Windows 98/ME. If you drag a window underneath the Adobe Photoshop splash screen (I'm using 7.0) you will notice that there is a rectangle around the splash screen that isn't updated. Photoshop uses the exact same method we do. Without using layered windows, there is no escaping the fact that there is ultimately nothing underneath your "transparent" window. We're using sleight of hand and I have no problem accepting that it isn't perfect (neither does adobe).

I'm assuming that you are implementing your splash screen by doing a screen capture and painting your splash image over it (showing the result on your form), i.e. ala photoshop, right? You probably ought to cache the screen capture image. Or, better yet, cache the composited image. Once you show your splash screen, whatever was underneath is gone graphics-wise and unless you cache it for later you're missing an essential element for your rendering. My recommendation for implementing this sort of splash screen is to create a backbuffer (a new System.Drawing.Bitmap), create a Graphics object on the bitmap, take a screen capture (using Graphics.CopyScreen), draw your splash screen image over it using Graphics.Draw and then set that image as your splash screen form's background. The redrawing will take care of itself. Another thing to consider is that Windows 2000/Xp+ supports for-real alpha blended forms using the "layered windows" feature, but if you take that route you lose support for alpha-blending on older versions of Windows.

The escape sequences are not part of the string. That is how the string is represented in c# code. When you see "\"C:\\\"" in the code, in the immediate window, or in a watch, that is the c# representation of the string "C:\" (quotes included). The backslashes are not actually part of the string. Your only problem is that the string contains quotes. I see that there are no quotes in there at design time, and I don't see any quotes in the code you posted, but at some point quotation marks are being introduced into the string.

The text of the tool strip label is "C:\" as opposed to C:\ You have the quotes included in the string. The reason for the error is that quotation marks are not valid in folder or file names. The reason for the extra backslashes is that the string is being displayed as a c-style escaped string, so this string "C:\" will be displayed with a backslash before each quote or backslash, with a pair of surrounding quotes, like so: "\"C:\\\""

When you want to destroy the buttons, simply remove them from the container (Form.Controls.Remove) and dispose of them (Button.Dispose).

Assuming that you are using DotNet 2.0 or later, and the number is the only contents of the text file, you could do something along the lines of the following: [Vb] Dim FileName As String Dim Lines() As String 'Contents of the files will be stored here Lines = System.IO.File.ReadAllLines(FileName) ' This assumes that the first line of the file contains a properly formatted number Dim Value As Double = Double.Parse(Lines(0)) ' Increment the number Value += 1 ' Store it back in the document Lines(0) = Value.ToString() ' Write the document back to the disk System.IO.File.WriteAllLines(FileName, Lines) [/code] I haven't tested it and some exception handling would be a very good idea, but that's the jist of it.

The former should look a little more like the following: Dim myLines As String() = System.IO.File.ReadAllLines(filename) (Assuming that we are using .Net 2.0 or higher)

I think that that is as simple as it is going to get. If you are going to do a bit rotation with a non-supported bit-size, you will always have to perform the carry yourself (i.e. the extra shift and 'or'). If you can safely operate under the assumption that only the least significant 3 bits are ever set, you can do away with some bit masking there.

If it helps, there is also the System.IO.File.ReadAllLines() method.

What is List1? A List(Of T)? A ListBox or ListView? And how are you loading the text file? Or are you loading a list of filenames?