Doing this as a COM component will allow you to use COM interop in your application, which is pretty easy to do. But if you don't know much about Windows programming, COM is even more difficult to learn so I wouldn't recommend it. Besides, deploying the solution requires that not only do you copy the COM DLL to a target directory but that you also register it (both not hard, but it's still a two-step process).
If you just make use of the GetOpenFileName and GetSaveFileName functions, along with the OPENFILENAME struct and a Win32 dialog template resource (all of which you'd have to do for the COM component anyway), you can encapsulate this function just like the default Windows Forms components that you want to replace. As I said before, use a good decompiler to see how they do it. Most of the controls in Windows Forms are just wrappers for native functions and controls, after all. I would recommend this approach. To deploy, just copy the DLL into your application's installation directory or somewhere in the PATH environment variable (like the Windows or Windows\System32 directory). I would recommend the application installation directory with the rest of your managed application though, since it would keep your files together and wouldn't clutter the system with DLLs that other applications might not use.
If i want to reproduce the functionality found in many microsoft apps, such as the windows on the bottom of vs7, that allow one splitter between two panels, to resize each panel as you move it left and right, how would i do that. I know that i can dock one, and fill the other, and have the splitter eat one of the panels area as you move the splitter, but what if you want both of the panels seperated by the splitter to resize so you dont crop any information?
It's all about the order that the controls are added to your form. Add a Panel, dock it to the left (for example), then add a Splitter (default is to dock left), then add your final Panel with dock fill. In code, it would look like this:
I could be wrong Heath, that that order produces the exact effect the original poster is trying to avoid. Attaching the (Dock=Fill) panel last, places it on the top of the Z-order - and therefore, it ignores the boundary set by the splitter.
For me, to get both panels to completely show up - resized, the first attached panel must be (Dock=Fill), and then the splitter and second panel must be (Dock=Left).
The (Dock=Fill) panel is attached first, and then pushed over by the attached, higher Z-order (Dock=Left) splitter, which is then pushed over again by the finally attached higher z-order (Dock=Left) panel.
If attached to a simple Form, the first panel (Dock=Fill) then shows up on the right, the splitter to its left, and the final panel shows up along the left edge of the form.
Both panels are completely visible and completely resizable.
Actually, panel1 in my snippet represents that far-left panel and panel2 the far-right. I numbered them accordingly to the original post's description, so what I typed and intended is exactly what you're saying now.
I, for one, do not think the problem was that the band was down. I think that the problem may have been that there was a Stonehenge monument on the stage that was in danger of being crushed by a dwarf.
I have a ListView control in which I'm loading a Progress bar as one of the sub items. Everything seems to be working except I'm having an issue when the column width is resized. Can anyone suggest the correct event to override to resize my ProgressBar when the Column width is changed ? Also is it possible to block the column width dragging ability in ListViews ?
You can block the resizing by overriding WndProc and handling the LVM_SETCOLUMNWIDTH message. If the Message.WParam cast to an int is the number of the column, don't pass the message on to base.WndProc. This should work. You should also be able to use this approach to get the new size of the control using some fancy state checking (allowing the column to be resized if desired) and setting the ProgressBar.Width property to the column width.
Is there any way so that all the below conditions give me true results.
String val = “Hello”
Now comparing val it with the following code.
1 “Hello “ //Note white space at the end of Hello.
2 “ Hello” //Note white space at the beginning of Hello.
3 “Hello “ //Note two white spaces left at the end.
4 “ Hello “ //Note white space both at thebegining and end of Hello.
5 “hello” //Note the caps change.
6 “HEllo” //Note the caps change.
7 "HeLLo " //Note one white space at the beggin and two at the end and also with caps change.
String.Trim is good to use, but as I told him before (no one listens), he should use String.Compare. This optionally takes case-sensitivety into account, as well as specific CultureInfo, which is necessary to use when worrying about globalized applitions. If you're not globalizing anything (and are 100% sure you never will), using what you wrote would work. Of course, to say that something in this field is 100% absolute will most likely lead to a hole in one's foot!
That's the worst possible idea - it's too expensive to compile and run and doesn't take culture into account. String.Compare does. All he needs to do is trim the string (String.Trim) and then use String.Compare.