I want to have a floating window in my app. One that is always on top of the main window...
But, if I make a form and set the TopMost property to true, the window is also on top of every other application.
I mean, when working in my app it works fine, but if i open another app in front of it, my floating window is also on top of that app... Not good...
"When a form is owned by another form, it is minimized and closed with the owner form. For example, if Form2 is owned by form Form1, if Form1 is closed or minimized, Form2 is also closed or minimized. Owned forms are also never displayed behind their owner form. You can use owned forms for windows such as find and replace windows, which should not be displayed behind the owner form when the owner form is selected."
The parent and the owner are too different things. Besides, to set the owner you use the Form.Owner property on the form that should be owned. The Form.OwnedForms property is a read-only property that is a Form array. Even replacing an element in the array won't set the Form.Owner property of the form you want owned.
Setting Form.Parent (inheritted from Control) won't solve this problem. Instead, set Form.Owner of the floating windows to the Form they should always overlap. See the documentation for Form.Owner in the .NET Framework SDK for more details.
Hello everyone, really struggling here......Can someone clear up a few issues for an inexperienced C# student...I need to implement a precise timer (ie not the ones supplied invisual studio.net)I need the timer component to act 1) like the .Net timers available ie. i set a time say 2 seconds and when this time has a elapsed an event is raised? 2) the elapsed time that raises an event may be less than 1 second that is something like miliseconds. 3)i implement several of these timers in one single application (perhaps using threads)?
Basically I am communicating serially with another computer (was quite difficult using C# until I discovered somewhere that you can use the MSCOMM control)... and I need to set up several timeouts. For instance I send several messages to the other computer and for each message I expect a reply in a certain amount of time. So I send a message and then I want to start a timer... when a certain amount of time elapses say 500 milliseconds then i want an event to be raised as a visual studio timer would do..... If anybody has any comments advice snippets of code with a little explanation or even other sources of help .... i would be truly grateful!
What's wrong with System.Threading.Timer? The TimerCallback is executed in a separate thread which is one of your requirements. For even more accuracy (according to the .NET Framework SDK), you can use a server-based timer like System.Timers.Timer.
If you want to use native function, you have to P/Invoke it and worry about marshaling parameters (depending on the native function called). The very act of marshaling could degrade accuracy over time, whereas the System.Threading.Timer is internally managed by the CLR. The other two call CreateWaitableTimer. So, basically, either you P/Invoke the methods or use the timers that do, or use System.Threading.Timer which should be about as accurate as you can get with the class library since it's managed internally by the CLR.
Firstly I thank you for your reply (i have never used a message board before). Secondly to bug you some more... I don't know if i was told the wrong thing but i was told that for automation purposes using operating system timers wasn't a good idea... do u have any thoughts on this?
When i say automation... my application will control a couple of robots....
If say I were to use the timers that you have mentioned above ... is there a way of finding out the resolution of their Ticks? also which of the above timers should i use? And you say that this is as accurate as i'm going to get?
As far as the resolution of the three timers in the .NET base class library go, the System.Windows.Forms.Timer uses the native SetTimer API, which uses time in milliseconds. System.Timers.Timer uses the native SetWaitableTimer and then uses a WaitableTimer (internal class) which calls SetWaitableTimer. This native function uses ticks - or 100 nanoseconds. Unfortunately, the System.Timers.Timer.Interval property takes time in milliseconds, thus decreasing the resolution. The System.Threading.Timer is mostly managed internally, so we can't know for sure how it works, but the documentation states that the interval is also specified in milliseconds.
So, the resolution of the timers in the .NET base class library is 1 millisecond. If you want to wrap CreateWaitableTimer, SetWaitableTimer, and CancelWaitableTimer in order to use ticks for better resolution, you can. The difference in time may make up for any time spent marshaling parameters. Of course, as long as you stick with the intrinsic types (int, long, double, byte, etc.), the SDK states that no time is spent marshaling since it is unnecessary.
As far as using timers besides those provided by the OS, I'm not really sure what else you'd use besides a timer card[^]. The resolution of a few of those cards isn't any better (some are even measured in seconds!) but you might get more accurate results taking only the hardware into account. Since each will most likely come with a C SDK, you might find yourself worrying about marshaling again.
Since you mentioned in your last post that these are to control robots, I would recommend you find some resources online regarding programming robots to find out how others accomplish that. The only experience I've had is reading a little about programmable robots with their own controller boards (a former-coworker of mine did the work, but I was passively curious at best).
"Not long time ago, I was programming an application for Windows that every certain time had to execute a task; in the development of the project everything went with normality but arrived the day to prove the program in the definitive machines where it had to remain working, and we observed that once in a while timers stopped working. We did thousand verifications always reaching the same result, sometimes, timers provided by the Framework don't tick, no events fired. It was then when we began to look for a solution to replace these timers and the solution that seemed better to me was the one to replace them by timers of the API of Windows. We looked on the Internet in case somebody had had the same idea that I had, without success, and therefore put hands to the work."
the address for this article is http://www.codeproject.com/csharp/FTwin32Timers.asp?target=timers
Does anyone have any comments? In my application i really cannot afford for a timer not to fire.
I have commented on this before. The timers in .NET use the Windows APIs! Perhaps there's a bug when they encapsulated the API calls, or perhaps the thread in which the elapsed handler was executed and the base .NET implementation didn't account for that. Either way, they still rely on the Windows APIs as most things do in .NET.
Use FTwin32Timers if you want. At most, maybe it has better exception handling. If you write your program well-enough, you shouldn't experience any problems since they most likely call the same APIs. Otherwise - as I mentioned before - look into a hardware-based solution but you'll be forced to encapsulate their APIs as well.
Im doing a project for the Uni and Im trying to find help for implementing a Control similar to the Inbox list on Outlook 2003.
Im coding in C# and so far I cant find something about it. I've tried using the ListView and DataGrid controls by doing some mods through inherit them into my class but no luck.
I want to have a list where I can add an item with parameters for the Name, Date, Subject mainly but also I want to be able to control the Icons and the flags(Not too much the flags). Plus having the main item as the Outlook has the day and the have my e-mail items as sub-items will be nice too.
Does anybody know something that might help me?????
Please let me know.
A ListView control is what you want to use, but you should look at the List-View Common Control[^] documentation in the Platform SDK. The .NET ListView control wraps the List-View common control - just as most other controls in System.Windows.Forms wrap respective common controls. There are several articles about overriding functionality in the ListView here on CodeProject and you can google for more. Previous Windows programming experience will be helpful because you'll have to P/Invoke several native functions (like SendMessage) and know how to send messages and handle notification messages by overriding WndProc in your derived Listview control. You'll also have to be familiar with marshaling, which isn't difficult, so you can declare your P/Invoke methods and structs appropriately.