Today I received my project description from Dr. Pankratz. It was not as scary of a task as I had thought comming into it. My project seems quite interesting and useful. I always thought it would be helpful to control my computer by remote control, but never dared trying to implement that myself. Although I am not quite sure where to go with this project, how I will do it or quite frankly even how or where to begin, I am anxious to get started with this project. I feel ready for the challenge ahead and look forward to creating a project that I and the SNC faculty can look back upon and be proud of.
Wednesday, January 15thI am just just begining to jump into my senior capstone project. Today I simply read the article that Dr. Pankratz gave me for my project. The article was in the May 2000 issue of Dr. Dobb's Journal. After reading it I got a better understanding of what my project was going to all involve. Now I began imagining in my head how I was planning on accomplishing this. Later in the day I also checked out the IRMAN's webpage. It was here where I found the device I would need to read the infrared signals, the IRMAN. Since I wanted to get started on this right away, I took this information to Dr. Pankratz office and we promptly ordered two IRMANs and an IRMAN remote control. The materials were on back order so I would have to wait till early February before I finally got an IRMAN to work with.
Working on some small MFC applications. One is attempting to control the system mouse. I am not exactly sure how I am supposed to do this. We always dealt with trapping the mouse not actually moving it ourselves and I seem to be having problems doing so. Going to go talk with Dr. McVey to see if she has any ideas.
Good news was received today ... the IRMAN is in! It was supposed to be back ordered for atleast another week. Now I can begin jumping into working with this new device. This should be fun.
Right now I am working on initializing my IRMAN infrared receiving device. The comm port is treated like a file so I need to first create it, then read and write from it. Dr. Pankratz has directed me to the dcc_comm code used by the Computer Controolled Railroad(CCR) to look at comm port functions. Using some of the code found there I tired to model my program off this. It is here were I ran into some problems. My computer was not even allowing me even to open the comm port. I tried many different ideas, all to no avail. Eventually, after several unsuccessful hours I called it a day, dejected and frustrated with my lack of progress.
Today I tired my program from the previos day on the Windows XP computers in the advandced computer lab in Cofrin. Here I was able to open the comm port without complication. I ran into problems once again however, when I was unable to read from the comm port. My program I created ran fine with no detectable errors, but as soon as I got to the code for the read from the comm port it just sat there. Since it did not return and error signal from the read, which I have it set up to do, it was either waiting to get something from the comm port but unable to do so, or I have some other problem. Once again, the day ends in rejection.
Thursday, February 6thA mini-breakthrough occured in the progress of my senior capstone project. So far the little begining programs have been causing me quite a bit of grief. This afternoon Dr. Pankratz and myself played around with the basic comm port application. Initialization for the IRMAN requires certain comm port settings that we were able to get at through the function set_comm_state. Then it requires that you write to it an "I" followed .5 seconds later by an "R". The device sends back an "O" and a "K" if everything is working properly and then you may begin using the IRMAN. We were able to successfully write the "I" and "R" and then read the "O" and "K" back from it. After this we were able to read the 6 byte codes comming from my remote control. There was a slight problem with the output since we were only able to see the first two bytes of the code in hex an all the remaining bytes were 0's. Well, this will give me something to work on this comming weekend.
My capstone project is taking a back seat for a couple of days to my graduate school selection process. Phil Busse and I were invited to take a venture north to come visit some of the Math and Computer Science faculty at Michigan Technological University. Phil and I apparently will be unable to fall back on what was believed to be promissing semi-truck driving careers. By some misguided directions and one huge missed turn we ended up entending the 4 hour drive into the U.P. to last well over 7 hours. We corrected our navigational error shortly before arriving in Canada or Mackinac Island. In meeting with various faculty members I got insight into their graduate programs and graduate school in general. My overall impression was that there was nothing to special here in the U.P. ... except of course for all that snow.
Still trying to get back form the U.P.
Today I tried to make up for my lost time this weekend. I spent the whole afternoon and much of the evening working on my capstone project. To my surprise I was able to get my idea of a history program working properly this evening. There were slight difficulties but after a little working they were overcome. The rest of my time was spent testing and analyzing the feedback my program gives. By using the IRMAN software I was able to check to make sure I was receiving and displaying the proper hexadecimal 6 byte code from the given keys I pressed. Of course, as has been the norm for this project, I have ran into some difficulty. It seems the IRMAN is much more sensitive then I thought as I can throw off the byte pattern I receive by not pointing the remote directly at the IRMAN device. Also, the byte pattern does not always seem to give back a constant result. Some buttons I am able to get up to almost 10 different byte patterns to display. Other buttons seem to alter byte pattern every time the button is pressed and still others have a different pattern for a pressed button compared with that same button pressed and held down. The later could prove to be useful as the held pattern could enhance the functioo of that button. For example, the CH+ button could move the mouse up, but if the held code is received it can mouse the mouse at a greater interval. I also for see problems arrising here as it is sometimes difficult to differ between press and pressed and held and the pattern just jumps back and forth. Still I feel great progress has been made today and I look forward to the upcoming week.
I was able to get my program up and running in a MFC Windows based environemnt. Using the code from my previous program (commport.cpp and commport.h) I was able to call upon the functions I have written to open the comm port. I then also was able to initialize the comm port and read from it. The only difficulty I had was my function to convert to hexadecimal was not portable to the environment and therefore my output is not to useful.
Dr. Pankratz and I met today. Since I previously was having problems with the displaying and storage of a command from the Irman in hexadecimal since moving over to the MFC based environment we discussed how to accomplish this. After we talked I was able to get the proper hexadecimal display and store this value as an array of 6 characters. I also was able to fix my start up problem. My program was having problems running on the Windows XP computers downstairs, but by simply clearing out the comm port buffer before initialization my program ran quite smoothly
Thursday, February 27thToday I met with Dr. McVey to look over my Microsoft Foundation Class comm port program. Since it as been a while since I have done this event driven code she pointed out a few easier ways to do things. We decided to use a CListBox to display the history which makes it easy to just add a new line. Also, we decided that it would be easier to make the whole window a CFrameWnd then I would be able to utilize the Menu capabilities that come with that since my current CDialog does not allow for that.
While working on my project in the lab professor Blahnik peered over and asked what kind of problems I was running into. With a simple glance at what I was doing he simply stated how much easier it would be to accomplish that in Visual Basic. After a half hour visit with him it became apparent that he was right. I know had a decision to make: either scrap my current program and start over in VB or continue my struggles in the more familiar MFC C++. The only thing I know for sure is I need to make a decision ... and quick!
After playing around with VB tonight I was quite impressed. I have not worked much at all with Visual Basic, but in a few hours I was able to make a history program that did not require polling. The VB format supplies you with a OnComm function that is called whenever any data is received in the comm port. With changing a few settings and learning how to output in hexadecimal, my event driven history application was complete ... something I was not able to figure out in MFC. From all that I read it required seperate threads and polling, something I did not really desire to do.
Wednesday, March 5th
|
|
|
|
Searched through the MSDN help pages and the internet to find access to the system mouse. Eventually found the function SetCursorPos which is an API function and needs to be declared using 'Private Declare Sub SetCursorPos Lib "user32" (ByVal x As Long, ByVal y As Long)'. Dr. Pankratz and I had thought that moving the system mouse would be a difficult task, but with a few hours of searching, I found the answer I was looking for.
Friday, March 7thSince I am dividing my project into seperate tasks, I was just trying to create a program that simulates mouse movement and clicks just with keys pressed on the keyboard. My program is working fine the only problem, which is a major one, is that once a 'click' occurs my application loses focus and what ever application was clicked on then is in control. My application is then not able to handle the input from the keyboard. This is a problem that I am not sure how to solve.
My answer to my Mouse Move problems has come to me in my dreams. I was lieing in bed and I just thought about it for some reason. I came to the conclusion that once I put what I had now under the control of the comm port it would work. The comm port is not a shared device so my application has sole possession of it. Therefore whenever data is received my OnComm function still handles that and can perform the action even if it is running in the background or minimized. This is not the case for the keyboard because that is a shared device and my application does not have control of it once focus leaves my program. With this knowledge I know am able to control all the movements of the mouse and am moving onto other things. Good time for a breakthrough with Spring Break right around the corner.
Thursday, March 14thDecision has been made ... I will be attending the North Carolina State University operations research graduate program next fall. In the end, their offer was just too good to pass up!
Some programming occured during this week, but the majority of my time was spent either on the beaches of South Padre Island, Texas, in the clubs or, unfortunately, on the two-way bus ride from hell! Next time I will pay the extra $300 and take a plane!!!
During break and the last few days I have improved the moving of data in my initialization of remotes form. I have 3 trees on this form for the users pleasure, but need to keep track of that data myself as well. Every now and then I still find an error that slipped past me, but for the most part I am happy with adding/deleting remotes, learning buttons and binding them to actions.
My application has complete control over the WinAmp and WinDVD actions. These programs I communicate with directly by using the SendMessage API call to the window. I was unable to find the message for closing the WinDVD and instead had to use a Keyboard shortcut, but other then that these applications seemed to be controled quite well by my PC Remote Control application.
Since perfecting the use of WinAmp and WinDVD I have moved onto other uses of my program. Currently I have implemented a cell phone text messaging style of text for my program. This means that when the application in focus accepts text I can send text to it. For example the 1 button could be bound with abcABC. If 1 is hit once an 'a' appears, if it is then struck again within a second the a disappears and a 'b' apears. In this fashion you can cycle thorugh the 6 different letter options (a...b...c...A...B...C..). I am quite pleased with how this turned out.
This afternoon I ran my program for Dr. McVey for ideas. She gave me good feed back with the most important being the idea of a status bar. This was instead of having error messages being report with message boxes that can be a pain, the status bar would indicate errors and succes. At this stage I also fully implemented the voice reporting of errors. I give the user an option of either displaying errors in just the status bar or having errors report through audio and the status bar.
Thursday, April 17thToday I met with Dr. Pankratz to show him some of the new enhancements I have made on my project. He prefered the new status bar which is much cleaner then using message boxes. The few suggestions he had included some consistancy issues with labels and with error messages in the status bar. DCP pointed out a huge oversight of mine ... I didn't have a delete button option. This would give me plenty to work on over Easter.
Saturday, April 19thI was able to implement the delete button function. I had thought about this previously and dismissed it, but since Dr. Pankratz brought it up it had begun to make more sense why I needed this function. I also further developed some of my pre-programmed actions. Microsoft Word is not a real appropriate application for this project since most users will be a distance from the screen where they may not be able to read text. Still I implemented some basic actions in Word so I can display my cellular phone text messaging style alphabet.
Met with professor Blahnik to show him my project and receive feedback. Helped me to make my program more user friendly. As I have found with talking to Dr. McVey and Dr. Pankratz, it is extremely beneficial to get input from the professors. The more people you get feedback from the more angles your program has been attacked from and, I believe, the better off it is for it. A few easy quick fixes from my discusion with Prof. Blahnik were made. Most notably would be my enhancements made to the setup of my program. Now the program thoroughly checks the comm port selected adn initializes the IRMAN automatically taking out some confusion to the user.
Well, the hard part is now over. My presentation had its good points and it certainly had its bad points (those who attended know what I am referring to). I was very upset with myself when my program did not work in the beginning of my presentation, but I figured what I did wrong. I had chaged something in the setup of the PowerPoint program that messed up what my program was attempting to accomplish. Ah well, nothing I can do about it now. The remaining part of my presentation I thought went alright. It sure feels good to be done. Now time for all the busy work of cleaning this up. Should be fun!