the copy menuitem isn’t always copying text. It isn’t greyed out on this window, but it doesn’t copy. I noticed another post about subclassing to tell if it even goes to the clipboard? Is there another way? I know it’s not disabled in the program. It works on other of my windows when, for instance, it’s readonly.
I’ve never had that issue, nor heard complaints from others of this problem. I suspect something else in your app. What is the control from which you are trying to copy text?
textarea.
I tried editcopy.enable and it didn’t change anything. Now it works if the field is not readonly. The other commands like delete worked before.
I agree. This makes no sense.
I just tried with Xojo 2013r4 and was able to copy text from a Read-Only TextArea to the clipboard. Create a simple project and try this. You will see that it does work.
Do you have any code in an EditCopy MenuHandler that may be intercepting this?
Is your textArea subclassed?
Any other code that may be interferring?
I’m sorry I wasn’t clear. Copy works on other windows in my program that are readonly. I also have no menuhandler for editcopy. The only other place it’s mentioned is in the menubar.
I have no more suggestions. As you are aware, it is not a Xojo issue but rather something about the single window in your program where the problem occurs. Keep looking, you’ll find it.
Good Luck.
Not too sure what else I can do. I created a menu handler for copy for this window. I added break points on every control or method in the window, including the keyhandlers. I went to previous window from which it was called. Nothing fires. Could it be something like a corrupted plist? What else can I do?
Since you can’t add menu handlers directly to an instance of a control on a layout a subclass would let you add them in the subclass.
Then change your controls on your layout to be instances of your subclass (just change the super).
Then you could put break points in the menu handlers in the subclass and that would tell you if they are getting called at all.
Sorry for asking a ‘newbie’ question, but I can’t figure out how to subclass it. I can make a new instance of my text area, but I don’t think that’s what you mean. Is there any tutorial on it? I avoid this stuff and one of these days I’ll get rid of my implicit instances too. I’ve been thru the doc’s and can’t find anything(unless it’s spelled sub-class or something else), and I’m not sure how to do this. Suggestions
Click “Insert” -> “Class”. Then make the “Superclass” of the class “TextArea” in the panel on the right. Then you can add methods, properties and event handler/definitions to your heart’s content.
You won’t find anything on how to create a subclass in the language reference.
That’s all just “you use this method/class like this” reference and not a how to guide.
The how to guides are the user guides which we ship with every release in the documentation folder right next to the IDE and accessible from the help menu. There are 5 PDF’s you can go through ( a learning to program one + the specific Xojo user guides)
Thanks. So it’s really a textarea in the App and not a window component. I hard code dimensions instead of using GUI to add to the window to the open event. - Yes?
I add the menu handler and other handlers to that class.
I think I can also drop the control on the app instead inserting it.
No, it’s still a window control, just with some additional functionality that you add in the class definition. You still drag one out to the window and place it there. Then treat it just like any other TextArea. Read through chapter 5 of the User Guide - Fundamentals book. Section 2 of that chapter discusses subclasses.
[quote=57516:@Arthur Gabhart]Thanks. So it’s really a textarea in the App and not a window component. I hard code dimensions instead of using GUI to add to the window to the open event. - Yes?
I add the menu handler and other handlers to that class.
I think I can also drop the control on the app instead inserting it.[/quote]
No - controls cannot be dropped onto the App class.
Its an instance on a window.
When you drop a button on a window your not adding a class to a window - you adding an instance of a button.
The class is like a cookie cutter pattern - when you put one on a window you get all the standard things that a button has.
But to make one button look & behave differently from another you need many different instances (you can kind of think of them as copies but they are not really copies)
So one instance you can make have the caption "Hello, and another “Goodbye”
Both are still buttons - they still look & act like buttons but they can have afferent properties & even have different behaviours when you press them - you write different code in each ones Action event.
Thats all well & good.
But sometimes you want a button (or other class) to do something special - not like the ones in the library behave.
So now what ?
That’s where subclasses come in. They do all the things the super class does plus whatever you add to them to specialize their behaviour.
But
all of this is covered in the books I mentioned.
We’ve spent a LOT of time writing them & its really in your best interest to read them as they cover all this.
Watch the webinars as well as they go through a lot of this.
Thanks and Sorry. I didn’t mean App class, but the potential executable (I guess). I did drop one control, a text area. It had the same attributes as a class I created. I have videos to watch. I know about classes. I just avoid them because my mind doesn’t handle the complexities.
Don’t avoid classes - you’ll have a very hard time that way - they can make code a lot easier to deal with.
And for getting started they can model real world things.
A person class might have a name, gender, height, weight, hair colour, eye colour etc if thats something useful in your application.
Or it might be a “Bank Account” class - it might have a balance, number, & perhaps a secret password to access it etc.
They are well covered in the introductory Learn to Program & Fundamentals books
I solved my problem interestingly. I switched from Carbon to Cocoa.