Links and linkClicked

[Timothy]

I'm afraid I'm not getting this. What's worse, I must have known it before, but can't remember.

I have two fields, I'll call them "Field X" and "Field Y", same background and same card, attributes the same for both fields. Both fields contain a valid URL. The textstyle of the text in both fields is set to "link" Both fields are locked.

There's an "on linkClicked theText" handler in the script of the stack with a RevGoURL command

Field X -- When the link is clicked, it opens my default browser and sends me to the URL in the field.

Field Y doesn't work.

With field X, this works:
on linkClicked
answer "OK"
end linkClicked

But this produces no response:
on mouseUp
answer "OK"
end mouseUp

With field Y it's the other way around.

I guess I have to set the something of something to something but I can't remember, and I can't puzzle out the rather terse documentation.

In the script of Field Y, I tried

on mouseUp
put line 1 of me into varOooo
set the linkText of line 1 of me to varOooo
answer the linktext of line 1 of me
end mouseUp


Then I tried

on mouseUp
answer the linktext of line 1 of me
end mouseUp

I do get the correct linkText answer to the mouseUp, but Field Y is still responding to "on mouseUp" and not to "on linkClicked"

What am I doing wrong?

Thanks in advance.

Tim

[oliverk]

Hi Tim,

It seems to me that you are doing everything right.

Have you tried moving your mouse over the link in field Y and using the message box command "put the linkText of the mouseChunk", this should return the link you want to open if the property has been set as you expected.

If you like, you can email me the stack and i'll take a look at it and see if it is a bug in Revolution and/or if there is a workaround you can use.

My email address is oliver at runrev dot com.

Regards

Oliver

[Timothy]

Hi Oliver,

You have probably identified the gap in my understanding.

If I understand your suggestion, I've got to put some kind of script or handler into the link, not the field containing the link, but I don't know how to do that.

I tried putting an "on mouseEnter" handler in the script of the field -- put the linktext of the mouseChunk -- but that produces an error. "Chunk: No target found" Actually, that apparently froze RR, requiring a force quit. Not sure why.

Does a link recognize mouseEnter?

Or am I on the wrong planet?

Thanks a bunch,

Tim

[Timothy]

Hello again,

I just realized that both fields X and Y are bg fields. Further investigation reveals that on other cards containing the same fields, both fields work correctly, if they contain valid URLs.

I entered the working links in fields X and Y several months ago. Trouble developed yesterday when I made some new cards and tried to enter new URLs.

I probably should write a script that starts by asking for a URL, in plain text, or getting a URL from another field, and ends up putting a working link into one of the fields in question. That way, I won't forget how to do this next time.

Any suggestions for a script like that?

Tim

[Timothy]

Okay, it looks like I fixed it.

Trivial? Bug? My stupidity? I can't figure it out.

Some links were sending mouseUp messages instead of linkClicked messages, even though the text style was set to "link." At least, I think it was set to "link" The linked text was blue and underlined. (It didn't turn purple after getting clicked, though. That should have ben a clue.)

I discovered the fix accidentally. Unlock the field, select the text in the field (a valid URL). Select the "Link" item in the "text" dropdown menu. Then select the "Link" item again.

After that, the problem links started sending linkClicked messages instead of mouseup messages.

In retrospect, I see that, for the problem links, there was no check mark next to the "Link" style in the "Text" dropdown menu, even though the selected text was underlined and blue. After turning "link" off, and then back on again, the checkmark next to the "link" item did appear.

I didn't move the cursor at all. Just selected "link" even though there was no checkmark next to it. The selected text changed to black and the underline went away. Still no checkmark next to "Link." Then selected "Link" again. The text turned blue again, the underline returned, and now a checkmark appeared next to "Link" in the "text" menu.

I'm going into all this dull detail because I wonder whether this was a bug or a user error. If an error, I must have been doing some teeny little thing wrong, but I can't figure out what it was. (Yes, the "List behavior" property of the field was unchecked throughout this episode.)

Okay, I know I shoulda noticed the missing checkmark next to the "Link" item in the "text" menu. I'll try to remember.


Tim

[marielle]

I just realized that both fields X and Y are bg fields. Further investigation reveals that on other cards containing the same fields, both fields work correctly, if they contain valid URLs.

That's a puzzling behavior indeed. Is it that you have some other object overlapping with field Y that could intercept mouse events... perhaps one with transparent parts? When various objects overlap, it is the frontmost one that will be the one to intercept the mouse events.

Note that if you need that functionality across the full stack, you can simply put the on linkClicked handler at stack level. You then have to be careful to erase any on linkClicked handler that you may have written at field level (otherwise the linkClicked event will be intercepted and processed at field level only).

Your script then become, at stack level:

Code: Select all

on linkClicked theText 
  if theText is empty then exit linkClicked
  if isWellFormattedURL(theText) is false then exit linkClicked
  revGoURL theText
end linkClicked

(minor variant of what is in the doc)

Note that isWellFormattedURL() is a function you need to write. As you asked a question about functions and handlers in another post, I added it on purpose, to give you an illustration in context. That function could be something as simple as:

Code: Select all

function isWellFormattedURL pURL
   if char 1 to 7 of pURL is "http://" then return true
   if char 1 to 6 of pURL is "ftp://" then return true
   answer "Err, I am supposed to receive an url as parameter but this really doesn't look like one."
      -- replace this answer with something more appropriate
   return false
end isWellFormattedURL

Note that though the normal syntax is if ... then ... else ... end, it is not required when you use return. Whenever a return appears in a function, the value that follows is being returned and the rest of the function is never processed.

There could be some advantages too to rather use this alternative function:

Code: Select all

function makeWellFormattedURL pURL
   if char 1 to 7 of pURL is "http://" then return pURL
   if char 1 to 6 of pURL is "ftp://" then return pURL
   put "http://" before pURL
   return pURL
   -- this way ou can simply write mydomain.com as link but 
   -- the user will be sent to http://mydomain.com
end makeWellFormattedURL

Keep asking questions, that's a good way to learn.