Local link in text field 1

[bfwriter]

Hello friends and pros,

Is there a means in my VFP 9 to embed a link in a text field (in this case a VFP Edit Box or an RTF Edit Box)--to open a file that's resident in the path of the LAN (i.e., not a hyperlink to the web)? For example, the text in the field might show "[Blah, blah, blah...] Click here for further detail." Where the "here" links to and opens a specified file.

My purpose is to avoid adding a separate form control to do this, because the requirement is very infrequent in the application.

TIA

Bill

 

[Mike Gagnon]

Just use an underline font and in the click event load what ever document you need.

Mike Gagnon

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[Mike Lewis]

Just use an underline font and in the click event load what ever document you need.

That will work if the link occupies the entire text field. You can go one step further by setting its MousePointer property to 15, which will turn the mouse into a pointing finger, which indicates to the user that it is a clickable item. And also set the ForeColor to blue, which is a standard colour for hypelinks.

But it won't work if you want to embed the link within a text field. In other words, this will be OK:

Click here to see the file.

But you can't do this:

Click here to see the file.

That's because VFP native controls don't allow you to change font properties for only part of the text. It's all or nothing.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

In an Editbox you can have hyperlinks, but it has several downsides:

1. _VFP.EditorOptions has to include a "k" or "K", see the help topic on it, don't just set _VFP.EditorOptions to "k" only, then you also switch off some very natural and necessary editor behaviours.
2. The Editbox and Textbox have the EnableHyperlinks property, which then works, when the general _VFP.EditorOptions works.

So far the preparations, of course the first downside is that this feature is quite hidden. But then you now haven't turned your editbox into a browser canvas. If you write out a link like [tt]<a href=targetURL>here</a>[/tt] this doesn't just display "here" in the underlined Hyperlink style. You can write URLs straight as they are into the EditBox value and VFP will detect them and make them active Hyperlinks, the display text stays the link URL. So this works quite like URLs work in many mail clients (even in text only mails) and like this forum works.

Now you can have URLs with file:// prefix pointing to files in the LAN, but that's it, you can't have the text display "here" and the document URL hidden as meta info.

Besides that, links then work as they work in mails. From the perspective of full control over events the downside is, the links just cause the usual OS behaviour to start up the standard browser (in case of http URLs) or the mail client with mailto: URLs and I just checked and see Word is started from file:// URLs of docx files.

But your Editbox.Click event code isn't run, so you only get what those URLs do by themselves, eg a file URL of a PDF would display the PDF in the standard PDF reader, likely, or in the standard browser. If the documents you're talking about are something specific to your application and you want a form of your application to come up with the document to (interactively) display, allow to edit and store changes in a database, that doesn't work out. If you're fine with Word starting up outside of your control and the user just doing anything he likes with the documents, which indeed means he can edit it, no problem, but also store the modification somewhere else without the link in your RTF changing accordingly. You get no feedback.

You could use a webbrowser control and obviously display any text including links, you then even get an event triggered by the link click in which you can allow the standard behaviour or do anything you'd like the link to cause. The task pane makes use of that and its source code also is available.

RTF control is maybe the simplest compromise, as in itself it allows not only colored text and other mixed text formattings but also hyperlinks, you just again have no control about what link clicks cause and you're not informed with feedback. Also users can modify text in an RTF control, but in itself it doesn't have a context menu allowing to format a selection as bold or add a URL, mainly the RTF control is the canvas of Word in RTF mode lacking the usual toolbars and context menu.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[bfwriter]

Many thanks to all--MikeG, MikeL, and Olaf.

MGagnon's suggestion won't work for me, for the reason that MLewis identified. (A click anywhere in the edit field will trigger the external call; which must remain unique to the "link" word/phrase, since the edit box, by its nature, expects clicks and edits anywhere, as the user requires.)

Olaf's multiple pointers tell me that a hyperlink with the file:// prefix (for local calls) is OK in a RichText Editor, which is indeed what I'm using here, and which does indeed have a HyperLinksEnabled property. And I do understand that a call to a .PDF or .DOC. or .WPD will open the called file in its own application--which will work here acceptably well.

But I don't know what, how, or where to place the code for the full path of the linked document to be opened. I have ruled out the possibility of a SHELL EXECUTE command, which needs to be placed in a separate form control, which is what I'm trying to avoid here. Perhaps any of you might be able to help me with this.

Many many thanks for all of your thoughtful help.

Bill
Rochester, Michigan

 

[Olaf Doschke]

You confuse me a bit. If file:// links work for you, you can use them. There is no further code necessary, just the file link. The only problem is of cosmetic nature, you can't name the link as you like, users will see the file link URL in its technical form, not "here". And all I said earlier, no need to repeat.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[bfwriter]

Many thanks for your response, and especially for your patience, Olaf. And my apologies for the confusion. My statement that...

...the "[tt]file:///[/tt]" prefix (for local calls) is OK in a RichText Editor, which is indeed what I'm using here...

is worded misleadingly. I meant that I regularly use the RTF editbox, but that I'm totally clueless about the structure and function of the link itself. (file:/// OR http:// OR any other).

Though I've been using VFP since the early 90s, I'm an autodidact amateur, and I've mastered only a narrow area of VFP and RTF coding for my own professional and personal uses. But I'm quite ignorant of many of VFP's other basic operations, and have never yet constructed a VFP hyperlink.

With kind thanks,

Bill

 

[Olaf Doschke]

file:// links are not VFP specific at all, you find all the info you need googling. But in very short, it's simply followed by full path and file name. That's almost all. since spaces are not allowed in URIs you change spaces to either + characters or %20.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[Olaf Doschke]

And in long:

https://en.wikipedia.org/wiki/File_URI_scheme

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name