snarfblam

Could the problem be that you are adding controls to the second form before removing them from the first?

The asterix signifies a pointer. For instance, look at the declarations below: int varA = 5; int * varB = &varA; varA is declared as an integer. varB is a pointer to an integer. (The ampersand, &, is the address-of operator, so the second line of code says "store the address of varA in varB."). Visual Basic does not have anything equivalent to pointers. (You can store them in IntPtr objects, but can't directly use the memory they point to.) As for GEN_SINT8 * title, I would say that it is looking for a string. I'm guessing that GEN_SINT8 is the same as a DotNet SByte (signed byte), but that isn't necessarily important. GEN_SINT8* would be a pointer to a series of 1-byte values that represent the title, a.k.a. an ASCII/ANSI string. Looking at our C++ signature, gen_setTitle(GEN_HANDLE_t, GEN_SINT8 *title);, it is asking for a handle (NOT a pointer to the handle, note the lack of an asterix, so use ByVal instead of ByRef) and a string (in the form of a pointer to an 8-bit encoded string). VB will marshal the string as a pointer to a series of characters, and I think ANSI is the default, but it won't hurt to be explicit. <DllImport("dll", [b]CharSet:=CharSet.Ansi[/b])> _ Public Shared Function gen_setTitle([b]ByVal[/b] handle As GEN_HANDLE_t, ByVal strTitle As String) As integer

Can you specify a culture in the ToString and Parse methods of numeric types to parse and output (or convert) the right formatting? For example, if you need to convert to the local culture, use Decimal.TryParse (or float/double) with an invarant culture, then Decimal.ToString with the local culture?

If you add an event handler to the Closing event (or override the OnClosing method) you should be able to check the e.CloseReason. That may help explain why it is closing. You can also set a breakpoint here and look at he call stack (try enabling "Show External Code"). You may see the which function is calling Close() in there.

It looks like the (C++) signature is: int gen_allocMsg(GEN_HANDLE_t *handle) If you aren't familiar with handles, just think of it as a value that identifies an object. In VB, generally an IntPtr value is used for handles. When dealing with p/invoke, I prefer to declare a struct for my handles for type safety and easy-to-read code. For example: Public Structure GEN_HANDLE_t Public handleValue As IntPtr End Structure You can then use this structure in place of IntPtr and you will always know exactly what kind of handle we are dealing with, making our code consistent with the documentation. The DLL method is looking for a pointer to a handle. It probably wants an address where it can put the handle for you. In this case you would declare the method like so: <DllImport("genDLL.dll")> _ Public Shared Function gen_allocMsg(ByRef handle as GEN_HANDLE_t) As Integer End Function The important part is the ByRef. With P/Invoke, a ByRef parameter gives a DLL a pointer to write a value to. Now, to use the function, call it like so: Dim myHandle As New GEN_HANDLE_t If gen_allocMsg(myHandle) = 1 Then ' We now have a handle to our new object ' stored in myHandle End If

Are you sure that Class1 has a value? I think an invalid/null index/key would throw an ArgumentException, and I don't know what else it could be.

You can wrap the unmanaged DLL in your own managed classes, but you would have to write all the wrapper code. If you are using the DLL in a non-trivial manner, it is probably best to wrap it one way or another. I'd be glad to answer any specific quesions, but if you are looking for guidance I would say your best bet is to seek out tutorials/tips/etc for P/Invoke, or even topics on accessing Windows API from managed code, as this is the most common instance of P/Invoke and most of the general information will apply. This is a plain-old unmanaged DLL, right? Or is it COM or something?

Which line are you getting the error on? Also, you should be able to hover the mouse over any identifier and a tooltip should pop up with the variable's or property's value.

I doubt you can use paint to open the image without saving it first. When you create the temporary file and launch paint, you can handle the Process.Exited event so you know when paint has closed. If you want to delete the file, there is a certain way you will need to load it. Load the file into memory with File.ReadAllBytes, then create a memory stream on the array and pass it to Image.FromStream(). Image.FromFile() will keep the file open until it is disposed, so you wouldn't be able to delete it.

There is a price to pay for apps using DotNet's comprehensive runtime environment and library. There are those who would argue that 13 megs is perfectly acceptable for a small app because "memory is cheap". I think it would be nicer to not use the memory when you don't need it. If you want a tiny memory footprint, C++ or even VB6 could be the way to go. As an interesting note, I was just looking at a discussion on SuperUser about full-featured media players with 5-10 meg footprints. Edit: I just created a hello world app, removing all unnecessary references, and got a 7-meg mem usage at start with a release build.

Sorry I'm having a hard time understanding, but are you generating the PNG masks?

I'm still not clear on where/how/why the masks are being generated. Can't you just generate different images int the first place instead of creating a single mask and trying to separate them out?

So you basically need to copy non-regtangular regions of pixels defined as the transparent area of a PNG? Assuming I understand correctly, you probably need to manipulate the raw pixel data of the images, scanning the "mask" png and copying pixels from the source to the destination when you encounter transparent pixels. Another option, if you are creating the masks yourself, could be to clone the original image (or the desired rectangular region), paste the mask with a solid color over the pixels you don't want, and use the Bitmap.MakeTransparent() method to exclude the masked region.

I'm not clear on what you are trying to do. Are you just trying to draw the image? Or create a new image that is a cropped piece of the original?

Why not check if it is the first subitem and if so adjust the width to the left bound of the second item?

Is what you are looking for the WebBrowser.DocumentText property?

This should go in its own thread.

I'd say you had it right the first time. If you implicitly imlement an interface, C# just assumes that the methods with the right names and signatures map to the interface methods. This is the most common approach. To implement an interface explicitly, you name your methods InterfaceName.MethodName. The methods will be "anonymous" (you can't access them directly from an object of the declaring type, and must cast to the interface type to call the methods). Explicitly implemented interface methods take precedence over implicitly implemented interface methods (if you define both, the implicit implementation is ignored). The option to implement an interface is per-method. The only reasons you would generally implement an interface method explicitly is if you want to: Give the methods different names than the interface calls for (Close versus Dispose) Change the signature of the method (usually to something more specific or strongly typed) Hide or abstract the interface implementation in the implementing class. Two implemented interfaces have conflicting method names To implement collection classes, I tend to inherit the List<T> class, rather than wrap it. If I need to modify behavior, I have an IList<T> wrapper class ready to include in my project and tweak as needed. This way I very rarely have to manually implement IList or ICollection. If you don't inherit an ICollection class then you will need to implement it yourself.

Some CDs have software that autoruns off the CD when inserted and prevents the tracks from being accessed on the PC. Very sketchy on the maker's part (I'm assuming the record label makes this decision). Have you tried disabling autorun?

The only problem with this is that, on average, half the source array must be re-written on each iteration. The alternative is to overwrite the used value with a dummy value, but then you must count through the array rather than indexing it, and that has it's own performance hit. Of course, if your list is sanely sized the real challenge would be coming up with a technique that doesn't perform well enough.

Is this C++? Can you initialize the backing field?

It looks like you are going from a pointer to a string to a byte array. I'm not sure if that is intentional. If the pointer points to the first char in the cCommand field this should be reasonably simple. Since command is always 8 bytes, you could do some pointer math to get a pointer to the "parameter". I don't foresee any padding/alignment issues here. How you encode the length is up to you (prefixed or zero terminated). But once you have a pointer you can use the Marshal class to get the parameter string. // Specify 8 chars, no length prefix or null terminator string command = System.Runtime.InteropServices.Marshal.PtrToStringAnsi(chRequest, 8); IntPtr lpszParameter = new IntPtr(chRequest.ToInt64() + 8); // With no len specified, this will work with a null ("\0") terminated string string parameter = System.Runtime.InteropServices.Marshal.PtrToStringAnsi(lpszParameter); ToInt64 (in theory) will work on both 32-bit and 64-bit, but I haven't tested this code on either platform.

I threw together a Q&D winforms app that picks out keywords, operators, and brackets and throws vB tags around them.

I find it to be extremely annoying that you can't easily access unfiltered key presses, but there is a way to get at them. When the Print Screen key is pressed, the virtual ProcessKeyMessage function is called on the control that contians focus. The tricky part that you have to be able to subclass the control and relay the message, and you may not be able to practically implement this if there is more than a few controls. As for checking keys in the KeyDown event, you should just be able to directly compare to enumerations values, i.e. C# Code[HorizontalRule]magic hidden text[/HorizontalRule]void MdiForm_KeyDown(object sender, KeyEventArgs e) { ··string val = e.KeyCode.ToString(); ··if (e.KeyCode == Keys.PrintScreen) { ····ScreenCapture(Environment.GetFolderPath(Environment.SpecialFolder.Desktop)); ····e.Handled = true; ··} }[HorizontalRule]Why are you quoting me?[/HorizontalRule] My point about ToString was just that Visual Studio was getting it wrong.

I believe that this problem stems from the fact that the Keys enumeration is a combination of both flags and sequential constants. Generally an enum should be one or the other. Otherwise it becomes difficult to sort out what the value means. The key code for the print screen key is actually 44. The "MButton | Back | Space" is actually Visual Studio trying to decode it as though it were flags. (If you call ToString on the KeyCode it will properly decode it.) What I believe is causing your particular problem as that you are also treating Keys as flags. The underscore key is actually primarily the minus key (OemMinus). When you test the expression ((e.KeyData & Keys.PrintScreen) == Keys.PrintScreen)), if minus (underscore) is pressed, the comparison done is ((189 & 44) == 44), which is true. Remove this bit test and your problem should go away.