g the
current first responder as the view to popUpContextMenu:withEvent:forView
This solves the issue but I do wish there was a way to make a context menu
behave just like the menus in the menu bar, with target set to nil, it would
adjust and send the action to the first responder.
Eyal
>
Hi Eyal,
I believe the target for a pop-up menu is the view that you pass in that
method, at least initially. If there is an established responder chain from
that view to other responders (up to and including First Responder) then the
menu items should reach their target. But it’s pretty easy
Hi,
I'm using popUpContextMenu:withEvent:forView: to show a context menu. The menu
contains several items whose target is the first responder (that is, nil). But
the items are not enabled and if I turn off autoEnable then the action is never
called on the first responder.
Same target/a
ArrayController, and the
>> (new) problem I have is that the editing of a cell ends after the first
>> keystroke. It looks as if first responder is resigned, but I can’t figure
>> out why, and as I say, this seems to be new behaviour.
>
> If you focus the cell again
first keystroke.
> It looks as if first responder is resigned, but I can’t figure out why, and
> as I say, this seems to be new behaviour.
If you focus the cell again and type, does editing end after _every_ keystroke?
Or can you continue editing properly after that?
Where does focus g
Dear list,
I have a new bug in an application which I believe has only appeared in 10.12.
I have a cell-based NSTableView backed by an NSArrayController, and the (new)
problem I have is that the editing of a cell ends after the first keystroke. It
looks as if first responder is resigned, but I
On Feb 16, 2017, at 12:43 , David Catmull wrote:
>
> I looked through the documentation, and didn't see anything that says you
> shouldn't call those methods.
Well, “encodeRestorableStateWithCoder:"
> This method is part of the window restoration system and is called at
> appropriate times to
I looked through the documentation, and didn't see anything that says you
shouldn't call those methods. If they were meant to be overridden and not
called, I expect they'd use something more opaque and special-purpose than
NSCoder.
As for being called twice, I don't see a problem, since they'll ju
On Feb 16, 2017, at 11:32 , David Catmull wrote:
>
> I am explicitly calling encodeRestorableState (in windowWillClose) and
> restoreStateWithCoder (in windowDidLoad).
You can’t. These methods — assuming you’re talking about overrides in (say) the
window controller — are called by the state re
ss of whether
it was open when the application last quit.
I'm using encode/restoreState because it's an existing mechanism that seems
to suit my needs, and aside from this first responder thing it's working
fine.
Also, I'm assuming - though I haven't tested this yet and
On Feb 16, 2017, at 10:09 , David Catmull wrote:
>
> I'm working on using encodeRestorableState/restoreStateWithCoder to save
> and restore the state of a window. (I'm doing this manually because I want
> to explicitly save my window state in the document and not just rely on the
> OS restoring i
ate.)
The problem I'm having is that when it restores, an error is logged in the
console that it can't restore the first responder because the view in
question has its window set to nil.
I tried calling makeFirstResponder(nil) before encoding, but then the
window is its own first responder
Doh! It’s iOS. Wasn’t paying attention.
> On Nov 11, 2015, at 6:16 PM, Graham Cox wrote:
>
>
>> On 12 Nov 2015, at 10:12 AM, Dave Fernandes
>> wrote:
>>
>> textFieldDidBeginEditing
>
>
> Sounds promising, but I can’t find that anywhere in the documentation. Where
> is it defined? (n.b. I
> On 12 Nov 2015, at 10:14 AM, Ken Thomases wrote:
>
> You can either use a subclass of NSTextView and override its
> -becomeFirstResponder method or you can use KVO to observe the firstResponder
> property of the window and, each time it changes, check if it's your text
> view.
Thanks - I
> On 12 Nov 2015, at 10:12 AM, Dave Fernandes
> wrote:
>
> textFieldDidBeginEditing
Sounds promising, but I can’t find that anywhere in the documentation. Where is
it defined? (n.b. I should make clear this is on Mac OS, if that’s iOS only I
can’t use it).
—Graham
__
On Nov 11, 2015, at 5:04 PM, Graham Cox wrote:
>
> I need to know when a text view becomes First Responder. I thought the
> notification NSTextDidBeginEditingNotification would do it, but that’s only
> sent when the user starts typing in the text view, which is too late for my
The delegate method textFieldDidBeginEditing: is called before the user starts
typing.
> On Nov 11, 2015, at 6:04 PM, Graham Cox wrote:
>
> I need to know when a text view becomes First Responder. I thought the
> notification NSTextDidBeginEditingNotification would do it, but
I need to know when a text view becomes First Responder. I thought the
notification NSTextDidBeginEditingNotification would do it, but that’s only
sent when the user starts typing in the text view, which is too late for my
purposes.
Is there another notification that I could use that signals a
So at that event or at the beginning of it resign first responder and manually
set the next responder.
You may need some logic to decide what is the next responder.
You may also need to ask the window to recalculate the next responder chain in
it.
Sent from my iPhone
> On Sep 29, 2015, a
.
The container needs to also to be able to handle keystrokes (arrow keys) and
for that purpose it access first responder implements keyDown.
The reason I'm handling arrow keys in the container is that there is a concept
of "selection" in that view and I want to allow the user to m
> On Apr 22, 2015, at 16:59 , Kyle Sluder wrote:
>
> On Wed, Apr 22, 2015, at 06:03 PM, Jens Alfke wrote:
>>
>> Kyle, you may have forgotten that -textFieldAtIndex: is a method
>> specifically declared in UIAlertView. It’s not some general-purpose
>> method inherited from UIView. The documentat
ng it focus seems like a perfectly reasonable thing to do.
This is complicated; first responder is a window-global state, so it
gets difficult to reason about interactions and dependencies.
It's not unreasonable to want the text fields of an alert to gain first
responder status when the alert a
> On Apr 22, 2015, at 1:34 PM, Kyle Sluder wrote:
>
> Accessing the subviews of a view you do not own is by definition
> "messing with the internals".
> ...
> Just because a method exists doesn't mean that it is OK for arbitrary
> clients to access it.
Kyle, you may have forgotten that -textFie
> that explains why others have reported success.
Your solution is to use UIAlertController on platforms where it exists.
It already has the correct first responder you desire.
--Kyle Sluder
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Pl
- (void)didPresentAlertView:(UIAlertView*)alertView
{
if (alertView.alertViewStyle == UIAlertViewStylePlainTextInput){
[[alertView textFieldAtIndex:0] selectAll:nil];
}
}
On Wed, Apr 22, 2015 at 1:21 PM, Rick Mann wrote:
> I don't think this qualifies as "messing with the internal
I don't think this qualifies as "messing with the internals." Apple provides
those methods. I'm not adding or removing views, or even moving them. All I
want to do is change focus. There are several posts on this approach that
report success. I'm not seeing it.
Provide me with a solution, or te
On Wed, Apr 22, 2015, at 03:16 PM, Rick Mann wrote:
> Stop. Making. Me. Abandon. Older. Users.
Nobody is making you abandon older users.
Use UIAlertView when running on older platforms.
Use UIAlertController when running on newer platforms, or continue to
use the UIAlertView compatibility suppor
Stop. Making. Me. Abandon. Older. Users.
> On Apr 22, 2015, at 12:18 , Kyle Sluder wrote:
>
> On Wed, Apr 22, 2015, at 01:53 PM, Rick Mann wrote:
>> In my UIAlertView -didPresentAlertView: delegate call, I'm trying to
>> change focus to the password field with
>>
>>UITextField* tf = [inView
On Wed, Apr 22, 2015, at 01:53 PM, Rick Mann wrote:
> In my UIAlertView -didPresentAlertView: delegate call, I'm trying to
> change focus to the password field with
>
> UITextField* tf = [inView textFieldAtIndex: 1];
> [tf becomeFirstResponder];
>
> But it's being ignored.
How many times
In my UIAlertView -didPresentAlertView: delegate call, I'm trying to change
focus to the password field with
UITextField* tf = [inView textFieldAtIndex: 1];
[tf becomeFirstResponder];
But it's being ignored. I've verified that it is the correct field. I'm doing
it in -didPresentAlertVie
rly when you hide the text view. You could try setting first
responder to something else: ‘[window recalculateKeyViewLoop]’, or perhaps
‘[window makeFirstResponder: nil]’ if you just want to get rid of it.
The blue highlight (it’s called a “focus ring” in Cocoa jargon) behavior does
sound lik
I am trying to solve a problem which seems to involve the first responder
for an NSWindow.
The NSWindow contains a number of controls and views, including several
NSTextField controls.
It is necessary to show or hide groups of these. These are all created
dynamically, rather
than with Interface
uess that's not how one
sends messages up the responder chain. I thought "nil" was a special case for
the first responder, but obviously that's not correct. There doesn't seem to be
a sanctioned way to get the first responder, which seems silly (which is IB
allowed bu
Hitting return results in the Table losing focus, the selected row
highlight
turns grey and controlTextDidEndEditing is never called.
Upon further research, it only does this when the column being edited is
included in the sort descriptors for the table view.
__
If I highlight a row in my NSTableView it turns blue and I can edit
individual cells. Tab jumps to the next column.
When I hit return however, the row turns grey and the table loses first
responder status.
I receive a proper controlTextDidBeginEditing once an edit takes place (ie
adding or
On Oct 4, 2013, at 12:30:51, Kyle Sluder
wrote:
> Given the volume and specificity of your questions, and the apparent speed
> with which you expect answers from this volunteer community, have you
> considered purchasing a DTS incident? Unlike this mailing list, DTS incidents
> come with a gu
> On Oct 4, 2013, at 10:17 AM, Steve Mills wrote:
>
> No ideas on this?
Guess not.
Given the volume and specificity of your questions, and the apparent speed with
which you expect answers from this volunteer community, have you considered
purchasing a DTS incident? Unlike this mailing list, D
first
responder unless Full Keyboard Access is turned on. Even if FKA is off I can
still tab to it and it gains focus. What else should I be doing here?
If I override makeFirstResponder: in our window subclass, I see that an
NSTextField is being set as the first responder when we tell the window
We have an NSControl subclass in a window. The class returns YES from
acceptsFirstResponder and canBecomeKeyView, and it overrides some NSResponder
methods (mouseDown:, keyDown:). The control is set to be the
initialFirstResponder in the xib. Yet it will not be the initial first
responder
On 2013 Jul 02, at 10:47, Steve Mills wrote:
> Perhaps Jerry is thinking of…
The document I was thinking of is …
OS X doc set
> Data Management
> Undo Architecture
> Using Undo in AppKit-Based Applications
> Undo and the Responder Chain
Usually it "just works" but if y
On Jul 2, 2013, at 1:53 PM, Steve Mills wrote:
> On Jul 2, 2013, at 12:10:22, Quincey Morris
> wrote:
>
>> There is a button, but it's obvious only after you know where it is.
>>
>> Select the First Responder item in the list of XIB components on the left of
On Jul 2, 2013, at 12:10:22, Quincey Morris
wrote:
> There is a button, but it's obvious only after you know where it is.
>
> Select the First Responder item in the list of XIB components on the left of
> the editing pane. Display the Attributes inspector in the pane at th
this, but the Undo and Redo
>> menu items in a Cocoa app are internally connected to some special magic.
>> They don't work like normal menu items.
>
> That's certainly not the case for any apps that we ship. And a brand-new
> Cocoa App created from template has
nnected to some special magic.
> They don't work like normal menu items.
That's certainly not the case for any apps that we ship. And a brand-new
Cocoa App created from template has Undo and Redo hooked up to First
Responder exactly as you'd expect.
--Kyle Sluder
___
here it is.
Select the First Responder item in the list of XIB components on the left of
the editing pane. Display the Attributes inspector in the pane at the right of
the window, and you'll see a list of custom actions to which you can add
actions.
__
On 2013 Jul 02, at 09:10, Steve Mills wrote:
> I finally got it to work by …
I don't recall which Apple document explains this, but the Undo and Redo menu
items in a Cocoa app are internally connected to some special magic. They
don't work like normal menu items.
__
choose undo:, but redo: does not appear in the list of known actions in
>> the First Responder. Any ideas?
>
> I have found that for whatever reason First Responder does not have all
> possible action methods in Interface Builder. The action is -redo:, so simply
> add it to Fi
In our MainMenu.xib, we previously had Undo and Redo hooked up to our own
actions, but now want to use the standard undo: and redo: actions. I'm able to
choose undo:, but redo: does not appear in the list of known actions in the
First Responder. Any ideas?
--
Steve Mills
office: 952-818
Developing a simple iOS app, I've run into a little misunderstanding about
First Responder.
On the Mac, the app's delegate gets messages intended for FR that reach
NSApplication, on iOS, that appears not to be the case.
My app needs a simple action method that can be accesse
and an array controller is filled with search results. Now, while the
>>> search field is the first responder, none of the Find items are enabled, so
>>> it is impossible to issue, say a Find Next command. The Find functions
>>> perform fine when just about any other
earch
>> field is the first responder, none of the Find items are enabled, so it is
>> impossible to issue, say a Find Next command. The Find functions perform
>> fine when just about any other item in the document window is first
>> responder. I find that surprising, but,
> is the first responder, none of the Find items are enabled, so it is
> impossible to issue, say a Find Next command. The Find functions perform fine
> when just about any other item in the document window is first responder. I
> find that surprising, but, more importantly, I cannot
Hi,
I have an NSSearchField, and a menu bar submenu with the standard Find items.
When the search field receives some input, it performs its action and an array
controller is filled with search results. Now, while the search field is the
first responder, none of the Find items are enabled, so
opover appear but have the NSSearchField never relinquish
>>> it's firstResponder status or have the NSPopover refuse firstResponder?
>>
>>
>> I think you'll need to ensure that none of the views in the popover accept
>> first responder, which is a p
> I think you'll need to ensure that none of the views in the popover accept
> first responder, which is a pain to do (and if they need to become first
> responder under some circumstances, might be impossible in the current
> implementation).
Worth a try but I have a
On 21/03/2013, at 12:53 AM, Brad Stone wrote:
> How can I have a popover appear but have the NSSearchField never relinquish
> it's firstResponder status or have the NSPopover refuse firstResponder?
I think you'll need to ensure that none of the views in the popover accept
Hmm. I can think of reasons why this might not work, but it's worth a shot:
Have you tried subclassing NSPopover and returning NO from
-acceptsFirstResponder?
--
Seth Willits
Yes, I tried that and tested that it was returning NO. It didn't work.
___
On Mar 20, 2013, at 6:53 AM, Brad Stone wrote:
> I'm trying to replicate the NSPopover functionality that the new iTunes has
> and I'm 99% there. The las problem I'm facing is when the NSPopover appears
> it steals the firstResponder status from the NSSearchField so the user's
> typing gets in
I'm trying to replicate the NSPopover functionality that the new iTunes has and
I'm 99% there. The las problem I'm facing is when the NSPopover appears it
steals the firstResponder status from the NSSearchField so the user's typing
gets interrupted when the popover appears. I tried giving the
On 11 במאי 2012, at 03:11, koko wrote:
> I have a menu item connected to an action in First Responder;
> The action exists in an NSView subclass.
> The subclass implements acceptsFirstResonder and return YES.
> The subclass implements validateMenuItem and return YES;
> When the me
Thanks for the courtesy of an edifying reply ... koko now grok more better.
On May 11, 2012, at 4:25 PM, Graham Cox wrote:
>
> On 11/05/2012, at 11:56 PM, koko wrote:
>
>> But what good is the responder chain if all views that acceptFirstResponder
>> are not part of it ?
>
>
> Because the
On 11/05/2012, at 11:56 PM, koko wrote:
> But what good is the responder chain if all views that acceptFirstResponder
> are not part of it ?
Because the purpose of the responder chain is to provide a context for the
keyboard and other shared inputs, like the menu bar. While the user can click
On May 11, 2012, at 8:28 AM, Fritz Anderson wrote:
> Your understanding that only the focused view (among views) can be first
> responder is correct. This is reflected in "responder" being singular and not
> plural.
koko grok
___
only the focused view (among views) can be first
responder is correct. This is reflected in "responder" being singular and not
plural.
Imagine a window with several NSTextFields. Imagine Edit > Select All being
selected. This sends a selectAll: message to the first responder (and u
On May 11, 2012, at 4:25 AM, Gregory Weston wrote:
> Absent from this narrative: Any indication that you have reason to believe
> your view has actually *become* the first responder.
The Window contains many views, each with a particular function to the
application.
Now, this ma
koko wrote:
> I have a menu item connected to an action in First Responder;
>
> The action exists in an NSView subclass.
>
> The subclass implements acceptsFirstResonder and return YES.
>
> The subclass implements validateMenuItem and return YES;
>
> When the men
On 5/10/12 4:24 PM, koko wrote:
> I have a menu item connected to an action in First Responder;
>
> The action exists in an NSView subclass.
>
> The subclass implements acceptsFirstResonder and return YES.
>
> The subclass implements validateMenuItem and return YES;
>
Could you please paste the a copy of the method in a message? It is far easier
to help you debug code which we can see than a description of something we
cannot see.
Erik Stainsby
erik.stain...@roaringsky.ca
-
On 2012-05-10, at 5:07 PM, koko wrote:
>
>
On May 10, 2012, at 6:05 PM, Erik Stainsby wrote:
> I have had this happen when I have forgotten to declare my action method in
> the public header.
The action is declared in the subclass header.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.co
On May 10, 2012, at 6:05 PM, Stephen J. Butler wrote:
> Does your subclass implement the action that the menu item is looking
> for? Your view subclass won't be chosen as the first responder if it
> doesn't implement the action
Yes, the subclass im
I have had this happen when I have forgotten to declare my action method in the
public header.
Erik Stainsby
erik.stain...@roaringsky.ca
-
On 2012-05-10, at 4:24 PM, koko wrote:
> I have a menu item connected to an action in First Responder;
>
On Thu, May 10, 2012 at 6:24 PM, koko wrote:
> I have a menu item connected to an action in First Responder;
>
> The action exists in an NSView subclass.
>
> The subclass implements acceptsFirstResonder and return YES.
>
> The subclass implements validateMenuItem and return Y
I have a menu item connected to an action in First Responder;
The action exists in an NSView subclass.
The subclass implements acceptsFirstResonder and return YES.
The subclass implements validateMenuItem and return YES;
When the menu displays the menu item is disabled (set to enabled in IB
On Feb 2, 2012, at 11:13 , Erik Stainsby wrote:
> I have a context menu in one window (A) from which I need to dispatch to
> another (B) window's First Responder list.
> Do I need to bring in a reference to window B (or it's controller) into the
> nib/code of window A ? Th
Hello list,
I have a context menu in one window (A) from which I need to dispatch to
another (B) window's First Responder list.
Do I need to bring in a reference to window B (or it's controller) into the
nib/code of window A ? This seems to go against loose coupling practices,
no? Or s
File a doc bug :)
--
Alex Kac CEO/Founder
On Jun 29, 2011, at 11:10 AM, Matt Neuburg wrote:
> Actually it works for more than text fields; another case of poor
> documentation. m.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do no
On 29-Jun-2011, at 11:56 PM, Matt Neuburg wrote:
> On Wed, 29 Jun 2011 21:12:50 +0800, Roland King said:
>> Is there a way to find out what UIResponder is the current first responder,
>> the one with the keyboard up?
>
> No. I devote some space to ranting about thi
On Wed, 29 Jun 2011 21:12:50 +0800, Roland King said:
>Is there a way to find out what UIResponder is the current first responder,
>the one with the keyboard up?
No. I devote some space to ranting about this in my book. The app obviously
*knows* who the first responder is, so why wo
Is there a way to find out what UIResponder is the current first responder, the
one with the keyboard up?
I have a number of editable fields, each on a cell of a table view which is in
a UIViewController managed by a UINavigationController. There's a couple of
other editable fields on
On 15 Jun 2011, at 23:12, Quincey Morris wrote:
> On Jun 15, 2011, at 13:12, Luc Van Bogaert wrote:
>
> As I said above, you aren't logging the responder chain, you're logging the
> nextResponder tree, and not even all of that. Plus, all three tree structures
> change over time as the UI is pr
down links, only up links.
I don't think "contains some text fields" is an accurate description. Your side
panel view contains a view which contains a text field. Since that text field
is first responder, the field editor (a text view) is displayed on top of it,
so what you
sable the creation of the
DSSidePanelView, but leave in the creation of the views in the other part of
the splitview, this is what I see:
2011-06-15 22:01:38.114 DotSketcher[3293:903] NSWindow
So now, the window's first responder is the window itself, or so it seems. Why
is that? Why isn
On Jun 15, 2011, at 12:12, Luc Van Bogaert wrote:
> Because things still don't work, I have tried to visualize the responder
> chain by adding this into applicationDidFinishLaunching:
>
> NSResponder *nextResponder = [self.window nextResponder];
> do {
> NSLog(@"%@", [nextRespond
On Wed, Jun 15, 2011 at 12:12 PM, Luc Van Bogaert
wrote:
> So does this mean my window doesn't have a next responder? If so, I'm
> completely lost about why that would be. But of course that would explain why
> the validation methods are never called.
Re-read Quincey's post. -nextResponder is N
o longer part of the responder chain.
>>
>> I used NSLog to find out the kind of object that is my window's "first
>> responder" and "next responder"; but the last method returns nil, which I
>> don't understand.
>
> I think there'
dd an extra view
> with some textfields to the content pane. Now, it appears that my validation
> method does not get called anymore, leading me to the conclusion that somehow
> my view controllers are no longer part of the responder chain.
>
> I used NSLog to find out the ki
On 14 Jun 2011, at 22:39, Quincey Morris wrote:
> When you connect an action to "First Responder", that doesn't mean that it's
> sent to the first responder object, but rather that it's sent to the first
> object in the responder chain that implements the actio
, I'm assuming I can not use IB to
reference the actual view objects contained in the nibs as the target for my
user interface items such as menu items and buttons. So, I decided to target
"first responder" instead, which initially worked well, but now seems to be
broken after addi
menu items and buttons in the interface use the target-action
> mechanism, but because of the previous design decision, I am targetting the
> "first responder" object instead of the actual view controller objects. When
> the user switches views held by the main window, I'
target-action
> mechanism, but because of the previous design decision, I am targetting the
> "first responder" object instead of the actual view controller objects. When
> the user switches views held by the main window, I'm making sure the selected
> view also be
e selected by the user at runtime. So the view controllers are not
instantiated in IB, but rather in code during runtime.
All the menu items and buttons in the interface use the target-action
mechanism, but because of the previous design decision, I am targetting the
"first responder" o
Jens,
This worked, once I fixed my typos. Thanks!
Eric Williams
AIM: wile...@gmail.com
Skype: wilersh
On Jun 1, 2011, at 1:49 PM, Jens Alfke wrote:
>
> On Jun 1, 2011, at 9:15 AM, Eric Williams wrote:
>
>> I want to set the first responder for the window to be a te
On Wed, Jun 1, 2011 at 10:53 AM, Jens Alfke wrote:
>
> On Jun 1, 2011, at 10:51 AM, Kyle Sluder wrote:
>
>> You actually want to use initialFirstResponder here. You can wire up
>> the window's initialFirstResponder outlet in IB to your text field,
>> and it will do the right thing.
>
> But the OP
On Jun 1, 2011, at 10:51 AM, Kyle Sluder wrote:
> You actually want to use initialFirstResponder here. You can wire up
> the window's initialFirstResponder outlet in IB to your text field,
> and it will do the right thing.
But the OP said he’s loading views into the window dynamically after it’s
n IB to your text field,
and it will do the right thing.
In the general case (where you want to set first responder sometime
*after* window loading) use -[NSWindow makeFirstRepsonder:].
http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSWindow_Cl
On Jun 1, 2011, at 9:15 AM, Eric Williams wrote:
> I want to set the first responder for the window to be a text field in the
> NSView after the view is loaded, so that a user can immediately start typing
> into the field.
After the view is loaded into the window, call
Probably fundamental but I haven't got my head straight on this.
Xcode 4.0.2
OS X 10.6.7
I have an app that is a single window that I load NSView elements over the
course of the life of the app.
I want to set the first responder for the window to be a text field in the
NSView after the
Wood, Tobias C wrote:
> Hello,
> I am trying to create a simple NSControl sub-class that will respond to mouse
> clicks and key presses, however I cannot get it to take First Responder
> status despite having over-ridden acceptsFirstResponder to return YES. If I
>
Hello,
I am trying to create a simple NSControl sub-class that will respond to mouse
clicks and key presses, however I cannot get it to take First Responder status
despite having over-ridden acceptsFirstResponder to return YES. If I place
breakpoints in acceptsFirstResponder and
On 27 Feb 2011, at 19:33, Graham Cox wrote:
>
> On 26/02/2011, at 6:19 PM, koko wrote:
>
>> Did you know that the average vocabulary is less that 200 words? And I be
>> penchant is not in that set.
>
> There are almost 1 million distinct words in English.
"The Global Language Monitor annou
1 - 100 of 187 matches
Mail list logo
