Foxhound is the better* Database Monitor for SQL Anywhere.
*better: More thorough, more relevant, more effective.
...more Alerts, more All Clears, more details, more control in your hands.

[Home] [Back to Tip 69] [Forward to Tip 71] [Archives]

Breck Carter
Last modified: February 5, 1997
mail to:

Tip 70: Accidental Polymorphism

How do I get the Clipboard() function to work in a DataWindow script?

In the grand scheme of things the advantages of polymorphism are outweighed by its disadvantages. That's because giving the same name to different things inevitably leads to confusion, and that's exactly what polymorphism is all about: The same names, and confusion.

Take the Clipboard() function for example. It comes in two flavors, the global "system level" function we're all familiar with, and a version specific to the DataWindow and DataStore controls. Both versions have the same name and both take a string argument but that's where the similarity ends.

Here's an example:

   clipboard ( "Hello, World!" )
If you put that statement in a CommandButton clicked event it will do what you expect: Put the string "Hello, World!" into the system clipboard. However, if you code it in a DataWindow event it won't do anything at all. That's because it uses the other form of Clipboard(), the one that expects the name of a graph as the argument and returns 1 or -1 instead of a string. And "Hello, World!" isn't the name of a graph.

How does PowerBuilder choose which one to call? Well, a CommandButton doesn't have an object-level Clipboard() function defined for it so PowerBuilder must use the global definition. On the other hand, the DataWindow control does have an object function called Clipboard() so even if you don't say "this.clipboard()" it will assume it. And call the wrong function. Yay. Isn't polymorphism wonderful?

There doesn't appear to be any way to force a DataWindow script to call the right function. One workaround is to define a global function of your own, with a different name like f_clipboard so PowerBuilder won't drag you into this polymorphic trap.

Define f_clipboard with a string return value and a single string argument, and a script that looks like this:

   return clipboard ( as_string )
Now you can call f_clipboard() wherever you want and there will never be any doubt about which function is being used.

This is only one example of the confusion caused by polymorphism, and it's accidental. Most polymorphism is done on purpose, and it's just as confusing.

[Home] [Back to Tip 69] [Forward to Tip 71] [Archives]
[mail to:]