1 of 1 people found this helpful
You can make an HTML image map with all of your "hover" areas. This tool is useful for that:
You can add your tooltips in the webviewer using the title attribute in the html image map code.
You want to link all of the areas on your map back to filemaker using the fmp:// URI scheme.
This article details that method nicely:
Scroll down halfway through that article and you'll see how to calculate fmp:// links.
With creative finagling, you could generate your links and map areas dynamically from stored filemaker table values, and compile everything in the webviewer at runtime. That's fairly complex though.
This should get you a starting point, I can elaborate if needed.
Thanks Mike, that was helpful - at least encouraging. I read over the hbase map discussion. It seems that they were dynamically building links into the web viewer html so that when one clicks on a pin, the correct window shows up. In my application, I have all my hover areas and attributes set. I can manually assign text in the link area (href) but I don't want to display another window or go to somewhere else. I want to pull data from the web viewer when the user clicks on the hover area. Here's aline of code for one area:
<area shape="poly" coords="183,92,174,125,207,103" href="#" title="right infraspinatus" alt="right infraspinatus" >
Currently the href is blank (#). All I need to do is get the text of the title, alt or href back into a field in my database when the user clicks on an mapped area. When the map is being displayed, no script will be running. Would I use "OnObjectEnter" script trigger to start a script? But the user might be hovering over several areas before deciding to click on one. Maybe I'm missing something and going down the wrong path. I think I need some elaboration if you don't mind.
If you change the # href to be a fmp:// URL which calls back into your database to execute a script (typically with a script parameter to pass click-specific data - in your case "right infraspinatus") everything will work fine. The user won't visually jump anywhere else, but your FM script will execute and you can do whatever you need to do. Note that this will only work on hosted databases or a standalone database on FM Go.
a couple of angles you could consider which are along the lines of those being discussed / offered.
1. you could bundle your solution with a polaroid type camera and instruct users to avoid pushing buttons but rather, snap a shot, wait 2 minute...@#@ my wife is reading over the shoulder and suggests this idea might suck.
If I understand correctly, while working within the webviewer, you want the click event attached to the html objects, which is displaying tooltips, to invoke a filemaker script and/or make the data inside the tooltip available on the filemaker side of things and not to spwan a new window or goto a target href, etc.
The function will simply init / declare a variable with the tooltip data as its value then concat a post request with instructions to trigger a script on filexxx.fmp12 and use the previously declared variable as your script param (which sends your tooltip data). The post request will be made to one of three places depending on how you are accessing the solution and where the solution is being run from.
option1_hosted solution: post request goes to your filemaker server.
option2_fmGo client with solution located on device: post requests goes to your mobile device.
option3_desktop filemaker with solution residing locally: 2 ways to handle this, both somewhat tricky. option 1 involves making a post request to a plug in which then relays the data to filemaker (digitalfusion or MBS). option 2 involves using a seperate solution which sits on a filemaker server and provides "relay" to your desktop solution. This relay solution is then setup as an external data source to your primary solution where you will likely use a single field as a transfer station. web viewer then fires off data to hosted relay solution, local solution picks it up as a refresh value.
All of these involve having a "catcher script" which is the script would call in all of your post requests. Its job would simply be to grab the script parameter and take action based on what is in the script param. In your case, the script param might be something like this (as a single string): "display||tooltipdata||reloadwebviewer||alternateurl"
your catcher script grabs the script param $sp=get(scriptparameter), then parses the indiviual parts ala Let ([ a=Substitute ($sp; "||";"¶"); action1=getvalue($sp; 1); payload1=getvalue($sp; 2) ....and so on). your script then has a bunch of case or if logic and takes action based on what you have setup.
If this is too convoluted, send me a message and I can fire you off some example solutions.
It's a tad late and I can feel this getting overly verbose so I'll button this up as an initial offering, more on demand if you find useful.
final thought - because you want the actions to occur while you are working inside the webviewer, with the webviewer having focus, you are going to get the best result by letting the webcode drive, as opposed to filemaker trying to poll and keep up with whatever you are doing.
I like your solution - it seems the easiest to accomplish. I inserted the following code but it doesn't call the script. What did I do wrong?
<area shape="poly" coords="183,92,174,125,207,103" href="FMP://10.0.1.102/TestWebviewMassage.fmp12?script=LoadAnatomy¶m=right%20infraspinatus" title="right infraspinatus" alt="right infraspinatus" >
I tried the param with and without the %20. This is being run on a standalone desktop - not over a server.
Thanks for the help.
I guess you missed the last sentence I wrote: this will only work on hosted files or FM Go. If you need this to work on a desktop you'll have to find another solution such as using the MBS plugin. Otherwise what you've got will work on a hosted or Go solution.
You've got some great answers here already. Perhaps you are already on your way to having this solved.
One detail that I would appreciate knowing is the platform(s) that you require this to run on, e.g. Windows, OSX, etc..
I appologize for the omision of that detail. I'm running on a stand-alone desktop with Windows 7 Pro with FMPA-12 v3.
Looking over your description, I think the option I am looking at is "option3_desktop filemaker with solution residing locally: " then "option 1 involves making a post request to a plug in which then relays the data to filemaker (digitalfusion or MBS)." My database file will have a "catcher script" that would expect a parameter (name of the muscle). I have a quiry into MBS to see which function they would recommend using. I haven't purchased anything yet. I assume there will have to be some java code in the html file to trigger all this. I'm an old Pascal programmer with little or no experience with java code (That's why I went with Filemaker). But given an example to work from, I think I could make an effort to get it to work. I really appreciate your effort in solving this problem.
Thank you for the extra information.
Long story short:
I thought I had an idea that would help, but am now somewhat convinced that I do not. Sorry!
Long story long:
For a minute I was thinking that you might be able to achieve the desired result in a non-hosted (i.e. stand-alone) environment without using a plugin, FMS, or any OnTimer/looping script.
This is because your particular interaction need is very simple:
One click in the webviewer triggers a script in FM.
The methodology would have been to soup-up your HTML with a little Javscript that modifies the webviewer source URL (something others have already mentioned in this thread), and then have a script that picks up the change in the URL and parses out the payload needed to have your FM script respond appropriately.
In times past, developers might have used a looping or OnTimer script that is constantly checking for the change in the URL, but in your case, you probably could have made it work by simply triggering the checking script once per click by utilizing an OnObjectEnter script trigger on the webviewer.
The reason that I am saying that this will not work in your situation is that I don't believe that your webviewer will respond to hover events until the user has actually clicked into it. Thus, the idea I'm mentioning above will not integrate well with the cool hover functionality that you already have working whereby the user can hover over a body part and see some text before they click for more info.
Sorry this idea does not pan out!
Bummer. But I went ahead and tested the hover action. Without clicking into the web viewer, when the mouse moves over a hot-spot, the alt tag displays. Of course it also displays when I have clicked into the web viewer field. Does this change anything for you?
Very interesting -- I'm surprised by your finding, but glad that you went ahead and tested the hover functionality rather than just taking my word for it.
On my OSX machine, the hovers don't work unless I have clicked into the webviewer.
Here's what I would suggest:
- Could you please do a little more testing and verify that even if you have first explicitly clicked somewhere else in the layout outside of the webviewer, that the webviewer still responds to hovering the mouse over the hot-spot?
- Also: Does it still respond to hover events if an OnObjectEnter script trigger has been applied to the webviewer?
If it truly still responds to hover events under these conditions, please let me know, and I will cook up a sample to show illustrate the idea that I considered and discarded.
Given what I have seen, I would not expect this technique to work on an OSX system, and, in general, I would consider it to me more fragile than the plugin route that ReelSteve and Mark DeNyse have suggested.
Nonetheless, it does no harm to see what we can accomplish through this idea.
p.s. I might not be able to post back until late tomorrow.
Sorry I couldn't get back to you right away. I did your tests and low-and-behold, the hover works no matter what. I added the OnObjectEnter script trigger for the webviewer and I even added another field. The hover worked even though I was in the other field (see screenprint). I also tried it when I had clicked on the background. At this point I'm not concerned that this might not work on a Mac. I just want it to work on Windows. Maybe later on I can get it working across platforms. I noticed that Matt Petrowsky has a video on jQuery and jQuery Tools, but I haven't studied that yet.
Thanks for your effort,
Thanks for being so diligent with testing this idea, and thanks for the screenshot. Like I said, I am surprised, but certainly I am pleased that we seem to have this avenue to pursue.
Given your success, here are two more questions for you:
1) How are you loading your HTML in the webviewer? Are you using the data:text/html (data URL) technique in the webviewer and supplying your own HTML, or are you simply pointing the webviewer to a URL for some external/hosted file?
2) Would it be possible for you to post a dumbed down version of the scenario (perhaps just a file with the layout in question) that I could tinker with and send back to you?
If it's not possible to supply a dumbed down version of what you've got, I understand -- I'll try to cook something up from scratch to send your way. The trick is that I am working on a Mac, and so I may not get things just right the first time to work on Windows -- we may need to shuffle the file back and forth a couple of times.
While I personally think that jQuery is one of the most significant, clever, and cool things to ever happen to the world of coding for the web, I do not think that it will be necessary for this endeavor unless you want to add more fancy stuff to your UI within the webviewer.