divil

A common and recommended design pattern in .NET is to have events raised by On[eventname] functions in the class. These routines should be virtual, so one can hook events externally or actually derive from the class and override. One can also then not call the base method and avoid the overhead of the delegates being called.

Because a dll has to be loaded in to memory, entry points found and all sorts of other issues like that. I see this question a lot and always find myself wondering what benefit a 1mb exe has over a 100k exe and a few dlls?

Those things are meant as incentives to buy the book, I would be very surprised if you were allowed to just post them somewhere publicly for anyone to download. If you wanted to use the knowledge you gained while learning from the book to write some samples that would be a better idea. And $1000? I thought I spent a lot when I first started learning .net and that was only $250 or so. And I still haven't read what I bought :)

As one of the arguments to the procedure handling the event, you are passed the node that was selected. You can use your own logic on this to determine what to do with it. Bear in mind that a node can be a parent _and_ a child, so this may not be as simple as it first appears.

Bootstrapping dotnetfx and mdac This is a very frequently requested topic, and Microsoft have come up with a solution to address it. http://www.gotdotnet.com/community/workspaces/workspace.aspx?ID=2F8F0A23-F529-4158-8E0A-D187D16F41F1 This plugin extends the VS Setup and Deployment project to support automatic configuration of a setup.exe that can bootstrap both the .NET Framework (1.1) and MDAC 2.7 as part of your application installation. This makes it easy to write a smart installer for your application that pre-installs these required components before your main installation starts.

That method would have to be called from the UI thread of your application. You can call any method like this by defining a delegate with the same signature, and using an existing control's Invoke method to call it. Having said that, the FileSystemWatcher class makes things slightly easier. If you set its SynchronizingObject property to your form when you create it, it will raise its events on the correct thread to begin with and hopefully circumvent your problem.

Maybe if you expressed it as a question and not a "challenge" people would be more inclined to answer. This is a question that has been asked here before, and the answer is that it is not advisable to start parenting top-level windows within your app. If you really need to, the process class exposes the handle of its main window, and you can use the SetParent api creatively to manipulate it.

Random sporadic mouse movements can happen with both optical and traditional ball mice. Sometimes when mine is just sitting on the mouse mat the cursor can decide it wants to move all the way to the left of the screen, slowly, and it does. A quick tap of the mouse and it stops as the light-sensors inside are re-aligned.

Look in to the ShowWindow api. You can call this on a window passing SW_SHOWNOACTIVATE to have the window shown but not activated, i.e. it pops up but does steal the focus. Like the Messenger windows. Also, you can use the SetWindowPos api passing HWND_TOPMOST to make that window the topmost window in the z-order on the screen. You have to use this api rather than Form.TopMost = true because doing the latter will make it steal the focus. You have to also pass SWP_NOACTIVATE to this api to stop that happening. I am told there will be a framework equivalent to showing windows without stealing focus in .NET 2.0.

I find that most of the development work behind an idea goes on in the back of my mind, until I have a very good idea how to solve all the potential problems and stumbling blocks that I can conceive of at the beginning. This all happens when I'm bored, when I have a free moment at work etc. And it all happens before I start bringing my ideas to life on a keyboard. Of course, the unfortunate thing is that I almost inevitably fail to spot all the possible problems that arise during the development process but still, I won't sit down to develop something without already knowing my path pretty well. I guess that puts me firmly in the second category.

It sounds like you don't want a messagebox, you want your own secondard form. You can design a form to be modal just like a messagebox is.

There is no reply because there are hardly any mobile developers yet, and hence no dedicated forum to the topic :)

Sounds like it's time for an upgrade ;)

GetHitTest is a better way of doing it that subclassing for messages in the designer. Also, you might try looking at the MouseDragBegin procedure of ControlDesigner that you can override to also provide this soft highlighting feature. If you plan on allowing the user to drag this subcomponent, using the built in OLE drag and drop methods is preferable too. The goal is really to remove all design-time functionality from the control itself and put it in the designer. The thing with GetHitTest is that your logic will still be in the control and not the designer, which actually carries a performance penalty.

That should still work just fine - OLE drag and drop is designed to work between processes let alone containers. The only thing I can think of is that perhaps your events got unbound when you were cutting and pasting controls between the containers. If I had this problem I would be sticking Debug.WriteLines in there to see what drag and drop events were actually getting raised, and if you're calling DoDragDrop as you should be etc.

The sheer lack of questions on this topic make it very unlikely that a forum will be created devoted to it.

SharpDevelop isn't stable enough (especially with VB.NET) to be much benefit over using Notepad.

How about, Application.DoEvents()? Finding out about that would have been as hard as typing DoEvents in to the help index.

The most effective way is probably to draw your own, then subclass for WM_NCHITTEST so you can tell Windows about your new size grips when it looks for them. Read up on this message in MSDN and that should help.

What about it?

MsComm is for serial communications, it knows nothing of the internet.

It depends if you really want to read it line by line. The fastest way will be to allocate a buffer of the right size to begin with, and just fill it with the contents, reading large chunks at once. If you really need it line by line you could then split this data on newlines, it would probably end up faster than reading the file line by line in the first place. You'll be looking at less than a second probably.

You have to create a new TypeConverter class for your listbox, and derive it from whatever typeconverter it uses as the moment. Then you have to provide a new way of converting to an InstanceDescriptor. This is the same way as in a few of the articles I've published. You then have to tell it to use your new constructor, and the designers will know how to serialize it properly.

It probably depends on the StringFormat you're using to draw the text. Use the CreateGraphics method of the radio button in question to get the graphics to measure from, then try passing StringFormat.GenericTypographic to the MeasureString method.

Derive your designer from ParentControlDesigner. If you don't have a designer, just associate ParentControlDesigner with your class via the DesignerAttribute class.