iOS How to disable copy/paste for text fields in 3.0 app

[boyplunder]

One of the apps I am working on is a database that I need to restrict the user to reference only. In the 3.0 software we have the added ability to select, copy and paste, but I don't want to allow the user to do that.

In earlier versions of the OS the text field could be set this way, but the copy/paste system seems to allow access anyway. The other issue that relates to the same access is that if text is selected, it often leaves a curser in the text. If I go out of the view and back again, the scrolled text shows the position held by the curser, not back to the top as I would like.

It works perfectly in 2.2.1, but does the above in 3.0.

My main views are in IB, with some elements just code, and I have altered all sorts of settings that indicate this is possible, but has no effect.

If anyone has an idea of methods I could use, please post.

 

[kainjow]

Maybe you could subclass the text field and override touchesBegan:withEvent: ?

 

[firewood]

Does copy/paste work, no matter what the textFieldShouldBeginEditing delegate returns?

 

[boyplunder]

Does copy/paste work, no matter what the textFieldShouldBeginEditing delegate returns?

Since posting the thread, I haven't had much time to try things out in code. Certainly the settings available in the IB controls do nothing to stop copy/paste access. Most of my base layouts are in IB, so I tried that route first.

In 2.2.1 the standard restrictions apply, as expected, but copy/paste is a whole level up it seems, and not managed by the IB controls. I need some user interaction because its a scrolling field. Maybe Apple will add this ability to IB in an update.

In the meantime, I'll have a look at textFieldShouldBeginEditing and see where I get with that.

 

[Saladinos]

"The UIResponder class declares the method canPerformAction:withSender:. Responder classes can implement this method to show and remove commands of the editing menu based on the current context."

"The menu initially includes all commands for which the first responder has corresponding UIResponderStandardEditActions method implementations (copy:, paste:, and so on). Before the menu is displayed, however, the system sends a canPerformAction:withSender: message to the first responder, which in many cases is the custom view itself. In its implementation of this method, the responder evaluates whether the command (indicated by the selector in the first argument) is applicable in the current context. For example, if the selector is paste: and there is no data in the pasteboard of a type the view can handle, the responder should return NO to suppress the Paste command. If the first responder does not implement the canPerformAction:withSender: method, or does not handle the given command, the message travels up the responder chain.

Listing 3-5 shows an implementation of the canPerformAction:withSender: method that looks for message matching the copy:, copy:, and paste: selectors; it enables or disables the Copy, Cut, and Paste menu commands based on the current selection context and, for paste, the contents of the pasteboard."

- (BOOL)canPerformAction:(SEL)action withSender:(id)sender {
    BOOL retValue = NO;
    ColorTile *theTile = [self colorTileForOrigin:currentSelection];
 
    if (action == @selector(paste:) )
        retValue = (theTile == nil) &&
             [[UIPasteboard generalPasteboard] containsPasteboardTypes:
             [NSArray arrayWithObject:ColorTileUTI]];
    else if ( action == @selector(cut:) || action == @selector(copy:) )
        retValue = (theTile != nil);
    else
        retValue = [super canPerformAction:action withSender:sender];
    return retValue;
}

From the ADC Reference Library Here

So basically, just return NO for the selectors cut: copy: and paste: in this method in the first responder or parent in the responder chain.

 

[boyplunder]

Thanks for that Saladinos, let's just hope it doesn't screw things up in 2.2.1 OS for users. I've had a bit of that recently.

The recent news that iPod Touch users are not taking the bait and not upgrading makes it more fun for any upgraded apps at the moment.

Here's one I posted earlier:

https://forums.macrumors.com/threads/730381/

 

[Saladinos]

Since this is a conditional statement, it shouldn't affect 2.2.1 users - it'll return false and nothing will happen.

However, I wouldn't worry about people not taking 3.0 up. There are loads of great APIs in 3.0 which means that sooner or later, people will have to upgrade. I think those statistics were taken far too soon after the 3.0 release.

 

[boyplunder]

There are loads of great APIs in 3.0 which means that sooner or later, people will have to upgrade.

'Normal folk' don't say 'What a great API list that is, must upgrade as soon as I get home!' They tend to say, 'Ah, credit crunch, I'll keep my 10 bucks for now. Maybe I'll do it next month.' An iPhone user, of course, doesn't have to make that choice.

Agreed though, those statistics did appear a tad soon.

 

[BlackWolf]

'Normal folk' don't say 'What a great API list that is, must upgrade as soon as I get home!' They tend to say, 'Ah, credit crunch, I'll keep my 10 bucks for now. Maybe I'll do it next month.' An iPhone user, of course, doesn't have to make that choice.

Agreed though, those statistics did appear a tad soon.

but normal folk says "hey, P2P gaming, sweet"