This has been covered countless times in this forum, including just recently. Please click the "Search Comments" link at the top of this messages box to find relevent messages and to see the complete threads.
I found a nice piece of code from the MSDN that does it. However this note was attached to it:
// PERFORMANCE NOTE:
// For ease of implementation, SecureClientChannelSink can take out some pretty big locks.
// Not a problem for demo purposes, but if this will be used as the basis for any kind of
// production level code, synchronization needs to reviewed and possibly greatly revamped.
Can anyone point me to an optimized piece of code?
Big newbie here, I hope I can explain my problem. I have two classes, Entities and Executants. I’ve added a reference (Entities) to Executants. The path is correct and when adding the using it did work at one time. Now for some reason my references aren’t working. I’ve tried to remove and add it again, but still not having any luck. Any suggestions as to how to begin figuring this problem out?
If the two Types are in a project in your solution (or if you can add it to your solution), right-click on the project that depends on these Types and add a reference, only click on the Projects tab and add a project reference. VS.NET will automatically keep track of changes and build dependencies when needed, as well as use the appropriate build (Debug, Release, etc.) so that everything is in sync.
If these were simply file references to some pre-built assembly, make sure you don't change the locations of those assemblies, even if they're in the GAC. VS.NET references file locations in other directories on your system - the assemblies in the GAC are used at runtime if the assembly names are the same as those referenced in your assembly manifest, or if you have change the runtime configuration in your app.config file.
Thanks for your response Heath. I believe what you suggested is what I've done. In the reference files within that one project displays the class I've added, but when I add the using SolutionName.ClassName, it's not available. At one time it was, but now it's gone. I have a twilight zone thing happening on my computer lol.
Namespaces can span multiple assemblies. If you're trying to access a class the assembly in which it's contained must be referenced by the assembly that needs to use that Type. The namespace may exist in the current assembly or another dependency, but the class exists in the one assembly. Make sure that assembly (not class) is referenced.
Assemblies contain not only the stuff I mentioned earlier, but all the Types defined in that assembly. A Type is a class, struct, enum, or delegate that is contained in a simple assembly. If you want to reference a Type from one assembly in a different assembly, you must reference that assembly in Visual Studio .NET (or using the /r param for the command-line compiler for the language in which you're developing).
For example, if you want to develop a Windows Forms application, you project must reference the System.Windows.Forms.dll assembly, as well as a few others like System.dll and System.Drawing.dll. If your application references another project (that compiles to an assembly), right-click on References and click Add Reference. Select the Projects tab and add your project (if it's in the same solution, otherwise use the .NET tab for .NET assemblies or the COM tab to add an interop assembly).
The using keyword used to "import" namespaces is only to save you from having to type the full namespace and class name, similar to the import keyword in Java. If you try using using with a namespace that is defined in another assembly (and remember, a namespace can span multiple assemblies so just because the namespace is available doesn't mean the class is available), then you must reference that assembly.
Remember, be sure to read about the .NET Framework and understand the concepts, such as .NET isn't limited to C# and - once compiled - the fact that the source was written in C# makes little to no difference (different languages compilers that target the Common Language Runtime, or the CLR, all produce Intermediate Language, or IL, with only a few differences depending on compiler optimizations and what the compilers supports).
You'll have to extend DataGridColumnStyle and make your own column style. It isn't too hard - especially when you don't have to worry about handling edits. See the DataGridColumnStyle documentation[^] in the .NET Framework SDK for more information, as well as an example that hosts a DateTimePicker control. Instead, you could host a PictureBox control and forget about handling the edit-related methods (unless they're abstract, in which case just don't provide any editing implementation) if you don't want users to be able to select a new image.
The best way to force a repaint when you resize a Control or Form (which derives form Control) is to override the Control and in the constructor (or some method that's called in the constructor) call SetStyle(ControlStyles.ResizeRedraw, true).
At any time, though, you can call Control.Refresh to invalidate the entire control and force a repaint. If you only want to invalidate a certain section, first call Control.Invalidate and optionally pass the region you want to invalidate, then call Control.Update to repaint the invalidated regions. You can always just call Control.Update to repaint any regions that were invalidated by something else (like a form passing over it, in which case a WM_PAINT method is sent by Windows anyway).
No you're not entirely wrong, but if you don't call Control.Update to force it to repaint, your control won't be repainted until the next WM_PAINT message is sent, which you have no control over. Calling Control.Update repaints the invalidated region immediately.
leppie's right about the positioning, but I must add that - according to the PSDK documentation - you can't display your form on top of the taskbar unless you use a borderless form and make it the size of the screen (a full-screen window), much like a screensaver.