Re: Is threading the right solution for this challenge?
- From: "James J. Gavan" <jgavandeletethis@xxxxxxx>
- Date: Thu, 04 May 2006 20:42:30 GMT
Oliver Wong wrote:
Oliver, not sure he is asking the question that you supplied an answer to :-).
I had a helluva job finding TIMEOUT - looked at the overall index for the N/E 4.0 on-line manuals and found following :-
http://supportline.microfocus.com/supportline/documentation/books/nx40/nx40indx.htm
So very often people ask a question here framed in a way that they understand, 'cos they know what they want to do - so they get answers based on what the reader interprets.
So The originator asks, "I've got a cart with a donkey which has a HUGE rock in the back. How do I get the donkey to move ?".
They get answers like "Entice the donkey with a carrot", or perhaps, "Prod a stick up its arse !".
But it turns out the originator has a solution for getting the donkey to move forwards. What he is really asking is "How can I get the donkey to go into reverse until I reach a cliff top so that I can tip the rock into the sea below !". (Naturally, he gets the donkey from out between the shafts before tipping the cart).
Net Express GUI classes allow "wantAllKeys" for a dialog; then on an event you go to a callback to check keystrokes. But Chris is in Unix - purely a (text) Character Mode display. (Might be a bit tricky for him to try mixing DOS/Unix-type Screen Section with OO events, in any language).
He has two choices coding programatically :-
ACCEPT Customer-Screen (all the screen fields making up the displayed record, automatically moving between the fields based on terminating with the <ENTER> key); OR
ACCEPT Customer-Account-Number (one specific field).
Now within the Screen Section/Panels that he is using there are various ways of terminating fields, and recognizing keystrokes or Function Keys - much too much to absorb in a quick read - I'm assuming Chris has checked out the On-line manuals on Character Handling.
My question to Chris - care to elaborate on why you need to keep refreshing the screen. (No doubt you have a good reason - but I'd like to know what it is). Using GUIs I only refresh screen when there is a CHANGE to say a Listbox or Treeview. One exception with Treeview - no changes and user clicks on the {-} or {+} appearing before Treeview Labels - based on the event you expand/contract the Treeview and then re-display.
I'm trying to establish if you want the donkey to go forwards or into reverse :-).
Jimmy
.
"Chris" <ctaliercio@xxxxxxxxx> wrote in message news:1146500082.954862.255300@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Compiler: MF SE 4.2 SP2
Platform: HP-UX 11i
Challenge: Have a continually refreshing display screen that also
responds to user input.
I had been considering using ACCEPT with a TIMEOUT clause and
refreshing after each time out, but that does not seem to be the
optimal solution here. In theory, this would give me a sluggish
application. Either the user would be waiting on the compilation of
display data, or the display would become "stale" while processing user
input.
I'm thinking that this is a prime candidate for me to tackle my first
threaded application. I figure I can run the user input interface in
one thread, whil running the continually updating output display in
another thread.
I don't have much COBOL experience, but the functionality you're referring to is commonly seen in games (e.g. update the screen, check if the user entered any input, and if so process it; either way, update the screen again and repeat). Usually in game development, you want to avoid threads where ever possible (an exception might be heavy duty 3D graphics processing, which I don't think applies to your case), as they tend to just add complexity without bringing too much benefit.
In ACCEPT with TIMEOUT, what happens if the user was in the process of entering data, and then the timeout occurs? Do you get the data that the user half-submitted, or do you get nothing? If it's the former, you could probably use ACCEPT with TIMEOUT, with a very low timeout (e.g. 1/100th of a second?), and just capture 1 character a time, constructing the full string of the user's input manually. If it's the latter, you might want to look into hooking into a library or API written in another language to provide you with the facility to capture characters one a time. See for example the "getch() function with no-delay" at http://www.mkssoftware.com/docs/man3/curs_getch.3.asp
Since I have ZERO experience in this arena, I wanted to throw it out
there for the masses and see what everyone thought.
In the meantime I'll be wading through the MF documentation on writing
threaded applications and try to discern what I can. What is the
typical method when designing a threaded application? Do I start by
creating the two individual applications and then work toward linking
them together, or are there other considerations?
There are many considerations when writing multithreaded code, and it's one of those things that's hard to get right. Code like:
MOVE 3 TO A
DISPLAY A
might not yield the output 3, if another thread has stepped in an modified the contents of A in between those two lines. There are techniques and data structures specifically designed for use in multithreaded programming (e.g. mutex, condition variable, locks, etc.), and entire books on writing multithreaded applications within a given programming language.
You might want to start at http://users.actcom.co.il/~choo/lupg/tutorials/multi-thread/multi-thread.html and work from there.
- Oliver
- Follow-Ups:
- References:
- Is threading the right solution for this challenge?
- From: Chris
- Re: Is threading the right solution for this challenge?
- From: Oliver Wong
- Is threading the right solution for this challenge?
- Prev by Date: Re: Static or Dynamic Call.
- Next by Date: 3-6 month contract in AL for a Senior Mainframe P/A with Cobol/CICS/DB2/VSAM
- Previous by thread: Re: Is threading the right solution for this challenge?
- Next by thread: Re: Is threading the right solution for this challenge?
- Index(es):
Relevant Pages
|
