I am running an application that uses a managed image list of icons pulled from the System kernel that uses extentions to look them up via a modified version Heath's little GetFileInfo source code.
The problem I have is, while my embeded resources, or any opened from the directory work fine in my XP visualStyle, with the alpha filtered ONLY at 32 bit ImageList settings, those that I pull from the system are still blocky and suffering from alpha textures showing up.
I am not sure what to do about this, I have written an algorythm to convert the pixels to RGB, but that leaves them on a black background. I don't understand why it occurs, as it does not occur else where.
By definition, alpha channels require 32-bit images because the first 24 bits are the colors (RGB) while the last 8 bits are the alpha channel.
As far as the problem goes, this has to do with the common controls version. If you use XP Visual Styles (either look at my article detailing this, or - for .NET 1.1 and up - call Application.EnableVisualStylesbefore calling Application.Run) most of the image handling code is redirected to common controls 6 (a side-by-side native assembly), which understands alpha channels. If not, the alpha channel gets converted to a close color like you've seen. .NET may understand alpha channels implicitly (which is why your embedded images with alpha channels work), but when pulling icons using file associations, you need enabled XP Visual Styles. This worked for me.
I've enabled the VisualStyles, with the DoEvents() methods.
Without those, even the embeded icons show the alpha texture.
I know it works, as the embedded icons, and those that I import from files (I unpacked the system icons from the DLL to experiment with them, and they work too), all come without the alpha.
What I don't understand is, when I construct the bitmaps from an icon handle, pulled from shell32, no matter what I do, the alpha is still there.
It's confusing me, because I can clearly see things working in some areas and others not.
I've set all my image lists to 32bit, and also added numerous 32bit reset points to test whether it was a drop in image quality that caused this. Still no luck.
(I have a screen shot of the anomaly, if anyone wants a look. It's confusing indeed...)
I found that the inline code documentation defined on the classes and methods does not get compiled into assembly! When looking into object browser, the documentation is only visible for the items found under project node. When coding in the project referencing the library containing the documentation, I only get class/method/argument names but no single word in addition.
The MSDN documentation says that the /doc compiler option should be used to produce xml file which could be used by IntelliSense - the file should have the same name as the assembly produced. I tried it but with no the effect.
Hi, this exactly I made but I made it using IDE, I did not run compiler from the command line. There is /doc configuration option int the project setting. The file was created but the documentation was not inserted to the compiled file.
Could you tell me, whether the /doc: dicrective works for you?
I'm trying to use the Microsoft.Win32.Registry namespace for getting owner information from the registry. I found that this namespace isn't supported by .net compact framework and that i have to use Win Api functions and to import coredll .dll
But I don't know how can I fix my problem:
I have to
and then to use RegCreateKeyEx(..) and RegCreateKeyEx(..)
Look at the System.Runtime.InteropServices.MarshalAsAttribute for some interformation. This should be pretty easy, though, and you should understand before proceeding. Basically, any handles become IntPtr, any strings become string (and in the DllImportAttribute you should specify the CharSet that's appropriate), DWORDs (and the like) become int, and structures must also be defined with appropriate attributes like StructLayoutAttribute. You should gain a good understanding of these. You also need to use the ref and out keywords appropriate based on the parameter type and the Platform SDK (PSDK) documentation ([in/out] translates to a ref, while [out] translates to an out).
As far as macros, you need to download and install the PSDK (if you didn't install it with VS.NET) and find it in the headers (the PSDK usually tells you what header it's in, otherwise search) and see what it's defined as.
Also, you could download a good decompiler like .NET Reflector[^] and look at the code for the Microsoft.Win32.Registry classes, structs, etc. This will give you some good idea of how Microsoft does it.
I need to 'associate' a Server Event to a Button via code. I built a Form, a Table, and a Button and I need to get a server event attached to the 'click' method for that button see code snippet below...
HtmlForm frmROPtbl = new HtmlForm();
Table maintable = new Table();
maintable.Width = Unit.Percentage(100);
TableRow hdrRow = new TableRow();
TableCell hdrCell0 = new TableCell();
TableCell hdrCell1 = new TableCell();
hdrRow.Width = Unit.Percentage(100);
hdrCell0.Width = Unit.Percentage(50);
hdrCell1.Width = Unit.Percentage(50);
Label hdrLabel = new Label();
hdrLabel.ID = "lblCustomerDesc".ToString();
hdrLabel.Width = Unit.Pixel(360);
Button btnToExcel = new Button();
btnToExcel.ID = "btnToExcel";
btnToExcel.Text = "To Excel";
btnToExcel.Click += new System.EventHandler(this.btnToExcel_Click);
//* Attach a Server Event to this Button
What do you mean by "server" event? Adding the Click event handler automatically renders the correct HTML. If you want the server to watch for something to happen, you can't for so many reasons:
HTTP is by nature non-stateful.
These two do not maintain persistent communications.
Isn't possible. .NET uses assemblies that contain dependency references, assembly attributes, modules (what actually contain the code), embedded resources, and a manifest that lists it all.
This does imply, however, that you could write a library and compile it as a module (only possible with the command-line compiler, csc.exe (C# compiler) using the /t:module parameter. You can then compile an assembly that contains your code plus this module. It's not quite the same thing, but the result is pretty much the same. Again, this is only available with the command-line compiler. VS.NET doesn't support this.
I have created a worker thread. Now I would like to create a separate window (form) to watch the progress of the thread. I specifically do NOT want to use an invoke back to the main form because I'm starting several such threads and wish to monitor them independantly. Obviously I would like the worker thread to directly create and show its own form.
Well I can easily create and show a form from the worker thread, however the form is not receiving window events and consequently nothing much happens.
What do I need to do in order to get this form to respond to windows messages?
Ohmygod. Do I feel stupid or what? Thank you John. I have no idea what I was thinking. Anyhow of course I didn't so the poor thread couldn't service events. In partial mitigation it is 11.47pm here and I have flu.
As you said, you can provide command line arguments in the Services control panel / snap-in.
If you need to configure the options in a different way, you could use a Windows Forms application that either uses registry settings or writes on a .config file (or other configuration file) for the service. You can use the ServiceController class to start, stop, or pause the service programmatically then.
If you want to configure the options while the service is running, you need to use the ServiceController.ExecuteCommand to pass a command identifier. If you need to change more complex options, you can use .NET Remoting over a TCP or HTTP channel.