PDA

View Full Version : C# Help



metaform3d
04-20-2008, 02:24 AM
I feel like kind of an idiot this sort of basic question, and I guess you should think of me as a type of newbie.

I need to create a Windows app that can control Phidgets and present an interesting GUI at the same time. I've done a lot of C and C++ programming and have created C++ Phidget classes and applications, but my experience creating a GUI from scratch is outdated and incomplete. Using what I know it would take forever to get anything up and running, so I wanted something a little more automatic. Based on discussions in this forum I decided that for my experience using C# would be the easiest approach. Boy was I wrong.

I ran through a bunch of tutorials and I was able to get "Hello World!" in a console but that was it. Anything involving windows or forms and I just get lost. So I have two questions:

1) can anyone recommend C# tutorials targeted to the experienced programmer who simply wants to get a specific job done -- hopefully a job involving making a nice UI?

2) is there any C# Phidgets sample code that does the kind of thing I want that I could just modify? What I'm looking for is a set of buttons in a window, perhaps the selection of which changes the window to show other buttons, plus different Phidgets behaviors that can run concurrently. Seems like basic robotics stuff, so it should exist if I knew how to find it.

Thank you in advance for any help.

Droid Works
04-20-2008, 06:20 AM
If you have any VB experience, VB would be better for what you want to do.

metaform3d
04-20-2008, 02:30 PM
BASIC -- yikes! I'll take a look at it, but it's hard to imagine writing anything useful in that horrible language.

Alex
04-20-2008, 02:49 PM
Moving from a command line style of programming over to GUI programming can be a bit intimidating at first till you have some decent examples to go off of.

I do have to politely disagree with you though Droid:)

If meta has a lot of C and C++ experience, then C# is the way to go with GUI applications. VB style syntax will give him one of the worst headaches he'd ever imagine. It's like trying to tell an airline pilot to try figuring out how to "drive" a submarine;)


One of the next features we're going to be focusing on adding here in the TRC is a tutorials section for things just like this. I have a TON of ideas that I'm going to be contributing and I hope that others will join in and contribute as well. There are so many areas of robotics that a tutorial for even the most basic, simple thing could help someone to take their next step in robotics. I can't count how many times in my experience after college that I ran into stumbling blocks during research for something and how quickly discouraged I became.

Ok, I'm done rambling, sorry about that:D

Meta - I can definitely help get you started with some demo apps here. Can you be a bit more specific with some simple apps and what Phidgets you are using so that I can build a couple of quick demos for you? I'm thinking that once you see just how easy it is to build Phidget apps in C# you'll really love it:D

Alex
04-20-2008, 02:55 PM
Moving from a command line style of programming over to GUI programming can be a bit intimidating at first till you have some decent examples to go off of.



I think Droid was actually referring to vb.NET, not Basic. Basic isn't even really a "GUI" language so to speak.

BTW, Droid, I realized I missed something in your post. I didn't catch the "if he had experience in VB" part, my bad.

metaform3d
04-20-2008, 10:50 PM
Actually it turned out to be useful. MS has a video series on VB intended for raw beginners so I watched some of that. Since VB and C# are under the same .NET umbrella and share a lot of the same UI, it was a useful primer just for Visual Studio. I'm starting to get enough of a grasp of what's happening to be able to pick apart samples, which is a start. I would definitely not attempt to program in the VB syntax, although it bears little relation to the BASIC of my youth.

I would be very interested to get some robotics-specific samples, especially of code that's needs to manage multiple tasks at the same time.

Alex
04-21-2008, 04:15 PM
I would be very interested to get some robotics-specific samples, especially of code that's needs to manage multiple tasks at the same time.
did you catch this in my reply above:


Let's start by pulling the discussion in this thread back to it's original intent, to agree upon a coordinate system and labels. Let's also just focus in on it being position and orientation stuff. Anything beyond that should get it's own thread.I don't know much about building multi-threaded applications (the ability to manage multiple tasks at the same time). I've talked to many people about possibly building a multi-threaded application in the past. You'd be surprised, anytime I thought I needed to create a multi-threaded application, other, more experienced developers showed me how I could write the same program where I wouldn't need to.

Adrenalynn
04-21-2008, 04:28 PM
Frequently, event-driven programming is the way to go. But [nearly] any time you have realtime requirements, threading will save your hiney.

metaform3d
04-21-2008, 06:55 PM
Yes, normally I would just use non-threaded functions that do their operation iteratively. So each one would read its inputs, set it's outputs, and then ask to be called back in some number of milliseconds. The main control loop would scan over them all and wait for the minimum callback time, while poling for input events.

Problem is in C# I have no control over the input loop. Once I return from a handler I have to wait to get called back again on an explicit event. I suppose what I need is a wake-up call. Is there a way to set a timer?

Adrenalynn
04-21-2008, 09:14 PM
I'm not the C# expert around here, but have a look at System.Timers and ElapsedEventHandler() - I believe if you search on either of those you'll find what you're looking for. No promises that it's the "best way", but it's what I'd try.

Alex
04-21-2008, 10:04 PM
I believe there is a limitation though to just how fast interval can be set with a System.Timer though, so look that up as well. I seem to remember reading somewhere that even though you can set the Timer.Interval property to be at 1ms, the fastest time you can get with expected results is around 55ms.

I just scooped this from this page (http://www.bcbjournal.com/articles/vol4/0011/Using_timers.htm?PHPSESSID=511e1300820f644e571a898 0cdf12921):




Limitations of the system timer



There are two important things that you should know about the system timer. First, this timer uses the system clock to perform timing. As such, the minimum resolution (the lowest interval you can effectively use) is about 55 milliseconds. You can certainly set the timer interval to a value less than 55, but the results will be unpredictable. This is particularly true on Windows 95 and 98. Windows NT and 2000 are less susceptible to this, but it is still not advisable to depend on the system timer for critical applications.



The second thing you need to be aware of when using the system timer is that it uses the WM_TIMER message to notify you each time the interval elapses. Of all the messages in Windows, WM_TIMER is one of the lowest priority messages. If the system is busy, WM_TIMER messages may be delayed. In some cases WM_TIMER messages may be removed from the message queue altogether. This means that a given timer event may not occur at all if the system is busy.



Considering these two factors, the system timer is potentially both inaccurate and unreliable. However, that is not to say that the system timer is unusable. Many tasks for which you will use a timer donít require a high degree of accuracy or reliability. Letís say you have an application that performs some service at 1:00 AM each day (a backup operation, for example). How do you know when itís 1:00 AM? You could use a timer that fires once per second and checks the current time. If the time is determined to be 1:00, then some processing is performed. In this example it doesnít much matter that the system timer is a bit inaccurate, nor does it matter that a timer message may be lost by Windows.

If you check out that link it talks about the multimedia timer which is supposedly more reliable than the system.timer and sounds to be more geared for applications like robotics. I say supposedly because I haven't heard of it till now.

Adrenalynn
04-21-2008, 10:08 PM
^^ See - like I say - "not the expert" ;)