divil

This is covered in the Windows Forms FAQ. http://www.syncfusion.com/FAQ/WinForms/FAQ_c94c.asp#q915q

Yeah, it'll certainly be nice to be able to change code without restarting the app, although it takes so little time I think I've just gotten used to it. The immediate window is also pretty useful for debugging stuff, but not many people seem to know about using it.

In your case it probably doesn't make much difference :)

Edit-and-continue is one of their biggest priorities for the next major release of VS.NET (the one after 2003).

Refresh forces the component to redraw itself immediately, and it is often not necessary to do this. Invalidate marks the control's surface as invalid, and next time the program is idle (i.e. when you have finished processing) windows will initiate the repaint itself. Personally I prefer Invalidate. Imagine in a large program you do several things in one loop that require the display to get redrawn. Calling Refresh each time would take time, but once a display is marked invalid you can go on marking it invalid any number of times, it is only redrawn when required. In a great deal of cases, both work equally well.

You should call Invalidate() then Application.DoEvents() if you're running in a loop, if not, skip the DoEvents part.

Why are you using that API to do it? To get the measurements for a piece of text on a graphics surface, use the Graphics.MeasureString function.

I'm pretty sure the .NET toolbar doesn't support changing the colours of the background and foreground. It only has those properties because it inherits them from Control.

The confusion lies in the fact that VS.NET will only run on Win2k and WinXP (both versions), whereas the .net applications you create with it will run on Windows 98 and later.

A listview will be passed by reference no matter if the parameter is declared byval or byref.

I got the email immediately but by the time I got to the forum someone had deleted the thread, so my guess is you submitted your request at the same time :) Thanks for taking the time to report the post, though.

Programs with animation, such as screensavers and games, tend to run in a main loop, using as much CPU as possible to render as many FPS as possible. In many ways they're easier to program than event-driven programs since your program never goes idle, and never leaves the loop. Basically you loop until a boolean contition changes, then the program ends. Somewhere in your loop you check for, say, a keypress to set that condition and the loop will finish. Rendering graphics depends whether you're using GDI+ or DirectX, but either way you will usually draw a frame every iteration of the loop. To do animation without DirectX, you use the GDI+ drawing methods in the System.Drawing namespace. Combined with the Windows Forms double buffering, this can produce a nice result. Every iteration of the loop you call Invalidate() then Application.DoEvents() and your main form gets repainted, and everything is drawn where it should be.

I couldn't find an option to turn off background compilation, but it's odd that it slows your code view down because it happens in another thread. Is this a particularly old machine?

Objects that are not value types are passed by reference regardless.

It's a question of informing the OS to load a different version of the Common Controls library (version 6) than the version the program was compiled to use (version 5).

I don't know whether it's fixed or not. I'll try to knock up an example of overriding WndProc tonight. If I forget, bump this post up to remind me.

Not really, there are no components that ship with the .NET framework that do this. You'll have to either write, or find one. No offence, but if you're not an experienced user, how come you're trying to do this? It's not really what I'd call easy.

You need to add a manifest to your application to enable XP visual styles. There are pages in MSDN on how to do this. You can also add a manifest to the IDE itself if you want visual styles to take effect at design time, but I strongly recommend against it, since doing so actually alters your resource files to make them unreadable by most people. The next version of .NET, due out in a few weeks, is mainly a bugfix release but contains a few nifty features, one of which is Application.EnableVisualStyles, which goes around the need to add a manifest entirely.

This is a confirmed bug in Windows Forms. If memory serves, one workaround is to override the WndProc to ignore the WM_SETFOCUS message, but I think that screws up the activecontrol property of the parent. I found the page where I saw it, and it's on the first post. The guy mentions the bug in passing. http://www.windowsforms.com/Forums/ShowPost.aspx?tabIndex=1&tabId=41&PostID=261

I can't believe you're not specifying parameter types on your functions. You should _always_ specify variable types, when declaring and when defining parameters. When you don't force strict strong-typing, you get errors like this one which are hard to trace. Go in to Project Properties and turn on Option Strict, that will force you to do this properly. Once it's on you should discover the cause of the error.

You'd need a serial communications component to open the modem port and send it the command to listen for Caller ID. I forget what the command is, but you should be able to find it.

I honestly can't see a way of doing what you want. You're restricted to using whatever RealPlayer can open, which presumably is just a file. You could always give the file a Hidden attribute I suppose. Just a thought, if RealPlayer can open URLs, you might be able to create a dummy webserver to serve your decrypted stream and have RealPlayer connect to that. A little far fetched, but then, so is your requirement :)

My knowledge of windows installer is by no means comprehensive, but I do know a bit. All you actually NEED to run a windows installer package is the .msi file. These are essentially executable, in that the MSI files are run by the windows installer program. All the other files created (the .ini, setup.exe, and the two bootstraps) are meant for people without windows installer on their machine. Windows Installer was first packaged with Windows 2000, and that version has been included with every Windows since (ME, XP). However, with .NET there came an updated version of it, so users need this updated version to install packages created with the .NET Setup and Deployment project wizard. This is why people usually include the bootstrap, because without it users won't be able to run the install package. However - I don't bother with the bootstrap, because when I deploy applications I rely on the fact that dotnetfx.exe (the .net runtime redistributable) installs the latest windows installer on to the machine. I use an autorun menu to give the user two choices, to install the .net framework and then install my application. Once the .net framework is installed the windows installer runtimes will be updated and they can run my .msi file.

They wouldn't make it more accurate, and if they made it any faster the difference would be negligible. I can't see a use for clipping regions with what you're doing, unless you really do need to restrict your drawing to one part of the form. The answer to your previous question is yes, it should make your drawing quicker, although you probably won't notice it as what you're doing won't be taxing the CPU much :)

You can probably keep a copy in memory using the MemoryStream class, but it's not meant to be a file. You can't access it like a file, and I'm pretty sure it's readonly too. There wouldn't be a way for RealPlayer to access it even if it _was_ meant to be an in-memory file.