Getting Return Key to Not Send Return Character? 
Author Message
 Getting Return Key to Not Send Return Character?

Maybe this is one of those problems where I'm just not framing it
right, but here's the situation:

I started writing a little program to act like a chat session. The
program says something in an EditField, then the user responds, then
the program responds etc. (a chatbot essentially). I have it so that
when the user presses Enter, the program responds on the next line,
then the user's "cursor" (their name with a colon after it) appears on
the next line, with the edit cursor right after it, ready for the next
input. I would also like it so that the Return key acts the same as
the Enter key (I'll make it as an option once I get it to work). But
if I have this code for the EditField's KeyDown event for example...

Function KeyDown (Key As String) As Boolean
dim newKeyVal as integer
newKeyVAl = asc(Key)

Select Case newKeyVal
  case 3 // user presses <enter>
   EditField1.SelText = chr(13) + Response + chr(13) + userCursor
  case 13 // user presses <return>          
   EditField1.SelTxt = chr(13) + Response + chr(13) + userCursor
end select

End Function

...then what happens is, the Return key even gets passed through, so
the EditField's cursor ends up on the next line. (The two Cases are
the same in the above code just to demonstrate how the behavior is
different). I've tried using SelStart and SelText to move the cursor
back, but that does not get rid of the Return. Is there a way to
prevent the Return from happening, or is there a whole different
approach to this that I am not thinking of?

I wonder if I should actually capture the entries of the user at a
lower level, such as at the Window class, then process it, format it,
and output it to the EditField, or rather a StaticText Field. However
having ther text in a static text field would not allow editing by the
user. I could have separate fields for the user and computer response,
but I'm not sure if I want to do that. In any case I still want to
know how to make Return = Enter and not pass through to the edit
field.



Wed, 21 Sep 2005 05:47:30 GMT  
 Getting Return Key to Not Send Return Character?

[..]

Quote:
> input. I would also like it so that the Return key acts the same as
> the Enter key (I'll make it as an option once I get it to work). But
> if I have this code for the EditField's KeyDown event for example...

> Function KeyDown (Key As String) As Boolean
> dim newKeyVal as integer
> newKeyVAl = asc(Key)

> Select Case newKeyVal
>   case 3 // user presses <enter>
>    EditField1.SelText = chr(13) + Response + chr(13) + userCursor
>   case 13 // user presses <return>          
>    EditField1.SelTxt = chr(13) + Response + chr(13) + userCursor
> end select

> End Function

> ...then what happens is, the Return key even gets passed through, so
> the EditField's cursor ends up on the next line.

Return True from KeyDown to let REALbasic know you're handling those
cases. Like this:

...
select case newKeyVal
  case 3
    EditField1.SelText = some text
    return true
  case 13
    ... etc.



Wed, 21 Sep 2005 05:53:15 GMT  
 Getting Return Key to Not Send Return Character?

Quote:


> [..]
> > input. I would also like it so that the Return key acts the same as
> > the Enter key (I'll make it as an option once I get it to work). But
> > if I have this code for the EditField's KeyDown event for example...

> > Function KeyDown (Key As String) As Boolean
> > dim newKeyVal as integer
> > newKeyVAl = asc(Key)

> > Select Case newKeyVal
> >   case 3 // user presses <enter>
> >    EditField1.SelText = chr(13) + Response + chr(13) + userCursor
> >   case 13 // user presses <return>          
> >    EditField1.SelTxt = chr(13) + Response + chr(13) + userCursor
> > end select

> > End Function

> > ...then what happens is, the Return key even gets passed through, so
> > the EditField's cursor ends up on the next line.

> Return True from KeyDown to let REALbasic know you're handling those
> cases. Like this:

> ...
> select case newKeyVal
>   case 3
>     EditField1.SelText = some text
>     return true
>   case 13
>     ... etc.

OK, that works. Thanks!

So, let me see if I understand this. REALbasic has an event loop, and
it registers events in the GUI, such as key presses or mouse
movements, constantly. The event handlers that belong to objects (like
EditFields) are being polled all the time too (when the corresponding
events happen), and if there is some code in one that pertains to a
triggered event, it gets run. But by placing "return true" in the
function of one of these event handlers (that has "as Boolean" in the
handler's function definition), RB knows that that kind of event is
being handled by that routine instead of RB's "native" event loop.
After this user routine is through executing, control or monitoring of
events goes back to RB.

-E



Wed, 21 Sep 2005 15:12:02 GMT  
 Getting Return Key to Not Send Return Character?

Quote:



[..]
> > Return True from KeyDown to let REALbasic know you're handling those
> > cases. Like this:
[..]

> OK, that works. Thanks!

> So, let me see if I understand this. REALbasic has an event loop, and
> it registers events in the GUI, such as key presses or mouse
> movements, constantly. The event handlers that belong to objects (like
> EditFields) are being polled all the time too (when the corresponding
> events happen), and if there is some code in one that pertains to a
> triggered event, it gets run. But by placing "return true" in the
> function of one of these event handlers (that has "as Boolean" in the
> handler's function definition), RB knows that that kind of event is
> being handled by that routine instead of RB's "native" event loop.
> After this user routine is through executing, control or monitoring of
> events goes back to RB.

You got it, generally speaking. Some events, like RectControl's
MouseDown also signal whether you should get other events, like
MouseDrag and MouseUp. And you can, of course, subclass controls and
make your own new event handling schemes based on the events your class
receives.

HTH.

BTW: I spent the last few days on and off learning how to customize
NSTextView in Cocoa so that I could make the Cocoa equivalent of an
EditField that catches return and enter keyboard events (make a subclass
and override keyDown:), and how to use my new subclass in the user
interface (which InterfaceBuilder won't let you do, so you have to
discard the IB instantiation and make a new one in code, which seems
horribly wasteful to me). So in this regard, REALbasic r00lz. :-)



Wed, 21 Sep 2005 18:28:15 GMT  
 Getting Return Key to Not Send Return Character?

Quote:




>  [..]
> > > Return True from KeyDown to let REALbasic know you're handling those
> > > cases. Like this:
>  [..]

> > OK, that works. Thanks!

> > So, let me see if I understand this. REALbasic has an event loop, and
> > it registers events in the GUI, such as key presses or mouse
> > movements, constantly. The event handlers that belong to objects (like
> > EditFields) are being polled all the time too (when the corresponding
> > events happen), and if there is some code in one that pertains to a
> > triggered event, it gets run. But by placing "return true" in the
> > function of one of these event handlers (that has "as Boolean" in the
> > handler's function definition), RB knows that that kind of event is
> > being handled by that routine instead of RB's "native" event loop.
> > After this user routine is through executing, control or monitoring of
> > events goes back to RB.

> You got it, generally speaking. Some events, like RectControl's
> MouseDown also signal whether you should get other events, like
> MouseDrag and MouseUp. And you can, of course, subclass controls and
> make your own new event handling schemes based on the events your class
> receives.

> HTH.

> BTW: I spent the last few days on and off learning how to customize
> NSTextView in Cocoa so that I could make the Cocoa equivalent of an
> EditField that catches return and enter keyboard events (make a subclass
> and override keyDown:), and how to use my new subclass in the user
> interface (which InterfaceBuilder won't let you do, so you have to
> discard the IB instantiation and make a new one in code, which seems
> horribly wasteful to me). So in this regard, REALbasic r00lz. :-)

That's a coincidence. Or perpahs not - maybe you were hunting for
comments on how to capture return and enter characters! And you end up
giving help instead of getting it. :)

Did you learn RB before Cocoa, and do you use C++ or Objective-C or?
(I looked at a book yesterday about programming  with Cocoa and
noticed how one could use various languages to do that. I then bought
a  book they recommended for learning C++ - one by Oualline -  with
the longer-range goal of getting into Cocoa programming eventually.
I'll just play around on the command line for now).

-E



Fri, 23 Sep 2005 02:05:39 GMT  
 Getting Return Key to Not Send Return Character?

Quote:



[..]
> > BTW: I spent the last few days on and off learning how to customize
> > NSTextView in Cocoa so that I could make the Cocoa equivalent of an
> > EditField that catches return and enter keyboard events (make a subclass
> > and override keyDown:), and how to use my new subclass in the user
> > interface (which InterfaceBuilder won't let you do, so you have to
> > discard the IB instantiation and make a new one in code, which seems
> > horribly wasteful to me). So in this regard, REALbasic r00lz. :-)

> That's a coincidence. Or perpahs not - maybe you were hunting for comments
> on how to capture return and enter characters! And you end up giving help
> instead of getting it. :)

Nope. :-) I found my answers on <http://cocoa.mamasam.com/>.

Quote:
> Did you learn RB before Cocoa, and do you use C++ or Objective-C or? (I
> looked at a book yesterday about programming  with Cocoa and noticed how
> one could use various languages to do that. I then bought a  book they
> recommended for learning C++ - one by Oualline -  with the longer-range
> goal of getting into Cocoa programming eventually. I'll just play around
> on the command line for now).

I learned C long, long ago, then RB when v.2 started getting publicity,
some C++ extensions in order to write RB plugins, and now Objective-C to
do Cocoa.

ObjC is, I think, best for learning Cocoa, since it's the native
language of the framework, and it's not that far a leap from
plain-old-C. (And also since it's just plain cooler than C++. <g>) If
you want to use C++ or Java you can branch out after you've got the
basics down in ObjC.

There are two good books for learning Cocoa: Hillegass' book, and the
Vermont Recipes one. I think the Vermont Recipes one is more recent and
up-to-date. Stay away from the O'Reilly one, but read their
macdevcenter.com Cocoa articles, especially the ones about memory
management.

:-)



Fri, 23 Sep 2005 05:29:36 GMT  
 Getting Return Key to Not Send Return Character?

Quote:




>  [..]
> > > BTW: I spent the last few days on and off learning how to customize
> > > NSTextView in Cocoa so that I could make the Cocoa equivalent of an
> > > EditField that catches return and enter keyboard events (make a subclass
> > > and override keyDown:), and how to use my new subclass in the user
> > > interface (which InterfaceBuilder won't let you do, so you have to
> > > discard the IB instantiation and make a new one in code, which seems
> > > horribly wasteful to me). So in this regard, REALbasic r00lz. :-)

> > That's a coincidence. Or perpahs not - maybe you were hunting for comments
> > on how to capture return and enter characters! And you end up giving help
> > instead of getting it. :)

> Nope. :-) I found my answers on < http://www.*-*-*.com/ ;.

> > Did you learn RB before Cocoa, and do you use C++ or Objective-C or? (I
> > looked at a book yesterday about programming  with Cocoa and noticed how
> > one could use various languages to do that. I then bought a  book they
> > recommended for learning C++ - one by Oualline -  with the longer-range
> > goal of getting into Cocoa programming eventually. I'll just play around
> > on the command line for now).

> I learned C long, long ago, then RB when v.2 started getting publicity,
> some C++ extensions in order to write RB plugins, and now Objective-C to
> do Cocoa.

> ObjC is, I think, best for learning Cocoa, since it's the native
> language of the framework, and it's not that far a leap from
> plain-old-C. (And also since it's just plain cooler than C++. <g>) If
> you want to use C++ or Java you can branch out after you've got the
> basics down in ObjC.

> There are two good books for learning Cocoa: Hillegass' book, and the
> Vermont Recipes one. I think the Vermont Recipes one is more recent and
> up-to-date. Stay away from the O'Reilly one, but read their
> macdevcenter.com Cocoa articles, especially the ones about memory
> management.

> :-)

Thanks for your thoughts.

Yes, I went to a technical bookstore looked at Hillegass' book
yesterday (after another thread recommended it). I also spotted the
Vermont one but didn't really open it up. What's wrong with the
O'Reilly books? (There's "Learning Cocoa with Objective-C "[Apple
approved], "Building Cocoa Applications: A Step-by-Step Guide", and
"Cocoa in a Nutshell: A Desktop Quick Reference" [being revised and
due in May]). My main goal at the store was exchanging the C++ book
for a C one.

As for learning C++, I changed my mind about that, partly because, as
you say (and I discovered), Obj-C is the thing to learn for Cocoa
development, and partly because I was turned off by some things about
C++. The "Hello World" example in the book I got used iostreams and >>
and << right away, instead of printf, without explaining them or even
a hint (such as these are blah blah and will be explained more later),
and this was confusing because I'd already started learning C many
years ago and did not expect it would be so different at such a basic
level. I thought the C++ object-oriented features were added on to the
langauge and would be introduced gradually, rather than an entirely
tran{*filter*}ed language (one that I'll have to ditch for Obj-C as it
were). I also read an op-ed piece about C++ in relation to Obj-C that
made it sound like the latter was better designed in some respects,
and that the OOP stuff is "layered" on:
http://www.*-*-*.com/

It's too bad that Obj-C is not very widely used and that C++ won in
the marketplace even though it's not as cool (Classic Steve Jobs /
Apple!). However, all the programming I've done up to now has been for
my own use, so that's hopefully will not be a problem unless by some
bizarre turn of fate I become a professional code jockey. Besides, I
could always learn it if I need to. The important things are the
concepts, understanding and artistry that underly programming and
computer science. (Maybe I should learn Scheme!).

Actually I did some C programming in a some years ago, around about
System 7 time, using MW Code Warrior - just some very simple apps -
but my knowledge is very spotty and rusty. Most of my programming,
other than some BASIC stuff I did in prehistoric times (including an
event loop GUI graphics program in MS BASIC for the Mac around 1985),
was HyperTalk (all of my business and much personal software), and a
little Prograph (anyone remember that?). And REALbasic of course. So
the other reason to upgrade my C understanding and not get into C++
before going on to Obj-C/Cocoa is that I already understand OOP to a
degree (it's always a matter of degree isn't it). I just need to fill
in and deepen my knowledge of C. This shouldn't take me long (knock on
wood), then I'll be ready to dive into Cocoa (I hope it's sweet ;).
Besides, C is what so much of the modern world runs on.

So basically, we've come to the same conclusions re C++/Obj-C. Having
to "go back" and re-learn C after the fun oF RB is a bit of a yawn,
but I figure once I get some learning under my belt such that I can DO
things, it'll start to get interesting again.

In the meantime too I'll probably still do som quick apps, utilities,
experiments, fun stuff in RB. It's great for that.

(Doesn't Nisus have a  mail client out done in RB? Is it good? They
make a good word processor...)

-Eric
eplatt No SPAM NO HOW at adnc dot com



Sat, 24 Sep 2005 03:51:46 GMT  
 Getting Return Key to Not Send Return Character?

Quote:

> and a little Prograph (anyone remember that?).

Gee, I think I remember it.  ;-)

Scott Steinman
"Visual Programming with Prograph CPX" (1995)



Sat, 24 Sep 2005 08:13:00 GMT  
 Getting Return Key to Not Send Return Character?

Quote:





>  [..]
> > > > BTW: I spent the last few days on and off learning how to customize
> > > > NSTextView in Cocoa so that I could make the Cocoa equivalent of an
> > > > EditField that catches return and enter keyboard events (make a subclass
> > > > and override keyDown:), and how to use my new subclass in the user
> > > > interface (which InterfaceBuilder won't let you do, so you have to
> > > > discard the IB instantiation and make a new one in code, which seems
> > > > horribly wasteful to me). So in this regard, REALbasic r00lz. :-)

> > > That's a coincidence. Or perpahs not - maybe you were hunting for comments
> > > on how to capture return and enter characters! And you end up giving help
> > > instead of getting it. :)

> > Nope. :-) I found my answers on < http://www.*-*-*.com/ ;.

> > > Did you learn RB before Cocoa, and do you use C++ or Objective-C or? (I
> > > looked at a book yesterday about programming  with Cocoa and noticed how
> > > one could use various languages to do that. I then bought a  book they
> > > recommended for learning C++ - one by Oualline -  with the longer-range
> > > goal of getting into Cocoa programming eventually. I'll just play around
> > > on the command line for now).

> > I learned C long, long ago, then RB when v.2 started getting publicity,
> > some C++ extensions in order to write RB plugins, and now Objective-C to
> > do Cocoa.

> > ObjC is, I think, best for learning Cocoa, since it's the native
> > language of the framework, and it's not that far a leap from
> > plain-old-C. (And also since it's just plain cooler than C++. <g>) If
> > you want to use C++ or Java you can branch out after you've got the
> > basics down in ObjC.

> > There are two good books for learning Cocoa: Hillegass' book, and the
> > Vermont Recipes one. I think the Vermont Recipes one is more recent and
> > up-to-date. Stay away from the O'Reilly one, but read their
> > macdevcenter.com Cocoa articles, especially the ones about memory
> > management.

> > :-)

> Thanks for your thoughts.

> Yes, I went to a technical bookstore looked at Hillegass' book
> yesterday (after another thread recommended it). I also spotted the
> Vermont one but didn't really open it up. What's wrong with the
> O'Reilly books? (There's "Learning Cocoa with Objective-C "[Apple
> approved], "Building Cocoa Applications: A Step-by-Step Guide", and
> "Cocoa in a Nutshell: A Desktop Quick Reference" [being revised and
> due in May]). My main goal at the store was exchanging the C++ book
> for a C one.

> As for learning C++, I changed my mind about that, partly because, as
> you say (and I discovered), Obj-C is the thing to learn for Cocoa
> development, and partly because I was turned off by some things about
> C++. The "Hello World" example in the book I got used iostreams and >>
> and << right away, instead of printf, without explaining them or even
> a hint (such as these are blah blah and will be explained more later),
> and this was confusing because I'd already started learning C many
> years ago and did not expect it would be so different at such a basic
> level. I thought the C++ object-oriented features were added on to the
> langauge and would be introduced gradually, rather than an entirely
> tran{*filter*}ed language (one that I'll have to ditch for Obj-C as it
> were). I also read an op-ed piece about C++ in relation to Obj-C that
> made it sound like the latter was better designed in some respects,
> and that the OOP stuff is "layered" on:
> http://www.*-*-*.com/

> It's too bad that Obj-C is not very widely used and that C++ won in
> the marketplace even though it's not as cool (Classic Steve Jobs /
> Apple!). However, all the programming I've done up to now has been for
> my own use, so that's hopefully will not be a problem unless by some
> bizarre turn of fate I become a professional code jockey. Besides, I
> could always learn it if I need to. The important things are the
> concepts, understanding and artistry that underly programming and
> computer science. (Maybe I should learn Scheme!).

> Actually I did some C programming in a some years ago, around about
> System 7 time, using MW Code Warrior - just some very simple apps -
> but my knowledge is very spotty and rusty. Most of my programming,
> other than some BASIC stuff I did in prehistoric times (including an
> event loop GUI graphics program in MS BASIC for the Mac around 1985),
> was HyperTalk (all of my business and much personal software), and a
> little Prograph (anyone remember that?). And REALbasic of course.

And I almost forgot: the lovely Python. That was very educational and
is helping with my C studies. I did some things in JavaScript too, but
wasn't crazy about it.

- Show quoted text -

Quote:
>So the other reason to upgrade my C understanding and not get into
C++
> before going on to Obj-C/Cocoa is that I already understand OOP to a
> degree (it's always a matter of degree isn't it). I just need to fill
> in and deepen my knowledge of C. This shouldn't take me long (knock on
> wood), then I'll be ready to dive into Cocoa (I hope it's sweet ;).
> Besides, C is what so much of the modern world runs on.

> So basically, we've come to the same conclusions re C++/Obj-C. Having
> to "go back" and re-learn C after the fun oF RB is a bit of a yawn,
> but I figure once I get some learning under my belt such that I can DO
> things, it'll start to get interesting again.

> In the meantime too I'll probably still do som quick apps, utilities,
> experiments, fun stuff in RB. It's great for that.

> (Doesn't Nisus have a  mail client out done in RB? Is it good? They
> make a good word processor...)

> -Eric
> eplatt No SPAM NO HOW at adnc dot com



Sat, 24 Sep 2005 12:20:14 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. Sending Return Key to SlipServer...HELP

2. Making return key act like tab key

3. Java Object Not Returned/Java Class Not Preserved

4. Return selected application window on mousedown and return to Realbasic

5. return -code return doesn't play nice with set

6. RETURN / RETURN-FROM and values

7. socket.send() returns

8. Return Key

9. return Key

10. Return name of key that is in use.

11. Returning Keys

12. RETURN character code in a STRING !

 

 
Powered by phpBB® Forum Software