"NSPasteboard objects transfer data to and from the pasteboard server. The server is shared by all running applications. It contains data that the user has cut or copied, as well as other data that one application wants to transfer to another. NSPasteboard objects are an application’s sole interface to the server and to all pasteboard operations.
An NSPasteboard object is also used to transfer data between applications and service providers listed in each application’s Services menu. The drag pasteboard (NSDragPboard) is used to transfer data that is being dragged by the user."
I found this in apple's NSPasteboard documentation. So far I only know how to use the pasteboard for simple copy-paste purposes. What I'm interested in knowing is how data for non-copy-paste purposes can be transferred through the pasteboard server between applications using contextual menus instead of drag-and-drop. For instance, if a user right-clicks a word and clicks "Look up in Dictionary" in the contextual menu, the word is then (presumably) sent to the Dictionary app through the pasteboard.
Can someone demonstrate a proof-of-concept app showing how to access data in the pasteboard server that stores words that a user has used "Look up in Dictionary" on?
It is not necessary for us to find the "Look up in Dictionary" pasteboard. (if there is one). But there is an NSPasteboard class method that sticks out to me for this use if you wanted to transfer data via pasteboard across your applications.
+ (NSPasteboard *)pasteboardWithName:(NSString *)name
Just use the same name for both apps and you can transfer data between them. Just make sure to call - releaseGlobally on this pasteboard when you are done with it.
Related
I need to provide printable documents without any ability (or a very minimized ability) of the user to view or download them.
I don't even have to render the document. They could just click a text link and have it blindly print to a printer.
This can be done using native applications, but it would be far better to provide this feature from a web interface.
Some points:
I can encrypt the document on the server so the HTTP GET response is garbled. The client could fetch a dynamic key from the server just before print to re-assemble the data. This would prevent snooping through a web inspector.
I could demand the use of a browser extension that sends print jobs without presenting print preview windows.
What other ways could a user get the document? What else should I be thinking with preventing?
I have an HTML web resource on a CRM 2011 form that users will be entering data into. This data will be required by CRM create/update plugins if the user chooses to save the main form, but there is no functional requirement that the data needs to be saved to any field on the entity. I am considering a hidden dummy field that the data could be saved to, but am wondering if there is anything more elegant for persisting data from the client to server technologies. I've done some research on "sharedvariables" but haven't been able to determine if they might meet this need. Any example of setting a value using JavaScript and then retrieving it from a plugin would be valuable.
Edit: I just wanted to clarify the response that I received based on my testing. While CRM has "SharedVariables" available for both plugin and scripting use, any data saved in scripts will not be available to plugins. Data saved by one javascript function to "SharedVariables" will be available to other javascript functions registered for the same event, and data saved by a plugin is available to other plugins registered for the same event, but the data is not persisted from script to plugins or vise-versa. This leaves dummy fields as the only option for persisting data from javascript to plugins. As NickNow suggested, unless you need to persist the data to a database, deleting it on a pre-plugin would be a good idea. Thanks Nicknow!
The hidden/dummy field is the correct approach. SharedVariables don't exist, from the standpoint of a plugin, until the data is sent to the server.
The form save is just a UI to trigger the Create or Update event - from the platform's standpoint you are just sending an entity logical name, the record guid (for an update), and the fields/values. The plugin has no knowledge, and shouldn't require knowledge, of how the event was triggered.
What I do is create a field (such as `new_internalmessaging') as a text field (since I'll never persist the value to the database I just make it a 2000 character string). During a JavaScript OnSave event I grab whatever data I need into an object and create a JSON string which I then use to populate the field.
In my Pre-Create and Pre-Update plugins I retrieve the string and deserialize it to an object for use in my plugin (I can also place it into a SharedVariable at this point if I need it for a post plugin). At this point the plugin code should remove new_internalmessaging from the Target.
I do this to ensure the data in that field will never get persisted to CRM.
there are many standard objects e.g. AccountcontactRole, LetterHead, Approval etc. which can be retrieved using Salesforce APIs. What is the way to see these objects in Salesforce environment in browser?
Very roughly speaking - easiest cheat is to simply put the Id in the URL. So if your Salesforce instance is https://na1.salesforce.com then adding /001.... (any valid Account Id) will take you to this account. Similarly /016... will take you to "this" Letterhead record.
Some data is easily accessible to users - for example AccountContactRole should be available as related list under Account. If it isn't - probably the administrator removed it from page layout because the company decided to use only the straightforward Account - Contact relationship.
Some data like Letterheads, EmailTemplates, Approval processes is visible in the setup area (not all users have the "View Setup and Configuration" permission in their Profiles!)
*Share records (like AccountShare) would be visible after you click the Sharing button on the page layout (if it's not visible - again, check with Admin).
If you're using API to fetch the data, you probably can also use "describe" calls to fetch info which objects are available, what fields are present in the tables... Sometimes the "Frontdoor URLs" property is set (although I confess I'm not sure how to get it, http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_Schema_DescribeSObjectResult_instance_methods.htm doesn't mention it).
Also - if you haven't noticed yet - all Accounts start with "001". Try to guess where "/001" and "/001/o" links would lead.
I'm trying to create an application using the knowledge i;ve learnt from Domain Driven Design.
My issue is that in my application I need to be able to create a new customer capturing the customers address, phone number, email address etc, would I just use the standard CRUD style here as this isnt really a task based action?
If all your application is ever going to do is to store customer data in a database, it's probably much better to use a simple CRUD style application. If the customer entry is just part of a bigger application, then it's perfectly reasonable to have a form to enter customer data (such as name, address, ...) - the data has to be entered somehow.
Just be aware of the differences between task-based and CRUD style forms: Say you'd want a customer to be flagged as verified, and for you have a state on the customer that can be "NEW" or "VERIFIED". In a CRUD-style application one would simply use a select box with the two options "NEW" and "VERIFIED" that changes the customer's state field. In a task-based UI you'd have a button/link in the customer form that reads "verify" and starts the "verification task", e.g., by sending a "verify customer" command to your domain layer.
Note that domain-driven-design is orthogonal to the concept task-based actions. They play well together, particularly when one uses CQRS, but they can both be used independently of the other.
I've got some nice little LotusScript that I can put into the Click event of an Action Hotspot in a rich text field when I'm sending an email manually. Is there a way to programmatically create that in the UI?
My script determines the user's home server and then opens a specific document in the replica of a training database on their home server. I could create these messages with hotspots manually and provide them to the folks who want to email them out. Of course, time being money and the task being boring, I'd rather automate it. I know that I could do this by using a stored form, but am wondering if the greater capability exists, as I can see further applications for it.
One trick I used in the past was to create a profile document in a database, and store some rich text in a field on that profile doc. Then when I needed to programmatically send an email, I could get that rich text field from the profile doc and use AppendRTItem to get it into the body of an email. That should work with any type of rich text, including hotspots.
Note: this won't work in the UI to populate a new email. It does work if you are generating the emails completely in code, though.