![]() |
|
|
|
|
|||||||
| Forums | Portal | Register | Forum Rules | FAQ | Contribute | Members List | Arcade | Search | Today's Posts | Mark Forums Read |
| High Level Programming Post questions about C, C++, Java, SQL, and other programming languages here. |
|
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Help with Data Positioning from Columns in a flat file. | oott1 | Shell Programming and Scripting | 3 | 06-14-2006 10:22 AM |
| Cursor Positioning | bestbuyernc | UNIX for Dummies Questions & Answers | 1 | 09-06-2005 05:50 AM |
| Get the cursor position | bestbuyernc | Shell Programming and Scripting | 0 | 07-27-2005 01:59 PM |
| Positioning curser at EOF in vi | JimJim | UNIX for Dummies Questions & Answers | 6 | 12-08-2004 02:20 PM |
| Cursor positioning thru VI Editor | Latha Nair | UNIX for Dummies Questions & Answers | 8 | 08-11-2004 04:56 AM |
|
|
Submit Tools | LinkBack | Thread Tools | Search this Thread | Display Modes |
|
#1
|
|||
|
|||
|
positioning cursor
I am using curses.h and signals.h to control output to screen. My code displays an unchanging prompt that waits for user input. Meanwhile alarm signals are being generated that cause other ancillary messages to appear at other locations on the screen at various times.
The problem I have is with cursor control. Every time an alarm signal causes an ancillary message to be displayed, the cursor moves away from the main prompt to the ancillary message. I can control this by manually repositioning the cursor after every ancillary message is displayed, but this all interferes with the user trying to enter input at the main prompt. If an alarm signal arrives when the user is halfway through entering their input, the cursor moves to the ancillary message for an instant then back to the starting position at the main prompt, interfering with entering of their input. Any suggestions? |
| Forum Sponsor | ||
|
|
|
#2
|
|||
|
|||
|
Have a look here Multiplexing with curses.
You need to treat the signals as another stream of input. A common technique I use is to create a pipe and include it as one of the input sources in a select(...) loop, in the signal handler I write a single byte to the pipe (usually the signum) and in the event loop I read the pipe. This avoids all the messyness of missing signals or interrupt system calls. All the signals end up queued in the pipe ready to be read following the select. |
|
#3
|
|||
|
|||
|
Thanks. I will check it out.
|
|||
| Google The UNIX and Linux Forums |