FMP had a great IDEA, but ruined it with a simple omission. The web viewer needs a URL, it can't display the content of a field that would contain HTML source code.

That's reall disapointing, it would have open a new wealth of opportunities, like previewing data.

Please make it in 8.5v2

Genevieve,

Welcome to FM Forums.

Your comment could be spot-on but since I really don't understand what you're saying I have no way help, agree, or disagree. Can you provide an explanation better suited for a simpleton like me?

She is saying that in addition to specifying a URL, from which the WebViewer retrieves and displays content, you should also be able to give the Web Viewer some web content in the form of a calculation or field content directly.

This seems logical, and would be a way, as noted, to preview web content contained in a field on the fly.

Alternatively just spit out the html file to a default location and have the url read of that?

Wow! I must be wearing my dunce hat this morning because with 3 explanations I still don't have the foggiest idea what any of you are saying.

Sounds like the desire is akin to using Dreamweaver or other editor to preview the html. Like Genx indicated, dump the field contents to a file and use the loction to view in the web viewer object. Even in other html editors you must save the file first. Another consideration is how FM interprets returns (vertical tab vs crlf) etc. The web viewer object is a cool way to make a pdf viewer of documents stored in the database in containers or by reference. Many other nifty uses too.

Okay, so is this discontent all about not having a way to work "off line" so-to-speak?

You can work "off line", you just have your URL reference a local file location. Check out the example file that comes with 8.5

The coolest thing I see is the crosstab report script that generates an HTML crosstab report from record data, saves the file to the drive, and then views the result in a web viewer.

The coolest thing I see is the crosstab report script

I agree, this seems to offer the most potential. Perhaps the end of preview mode and way too many layouts for reporting? Viewing websites and parsing out html is nifty and all, but a bit of a garnish compared to this. The ability to now render and display in an external language without IWP, CWP, or an external application seems far more powerful. 27 days left to figure it out...

Might there be a way to use FM's web publishing capabilities for this?

Hmm, like using FM desktop to interact with itself as a webclient at the same time; a single person-multi user?

The sad thing with FMP is that you spend your time doing workarounds. I though about FMP webservber to itself stuff, but How cumbersome is it, and how expensive.

If only they allowed the source of the webwiever to be html text aside being a URL, it would have costd them nothing in development time and helped us a lot.

In fact I'm "mad" about such an oversight, because every webbrowser on earth can render html text, they do not require a URL. So it seems obvious that if you do a webviewer, it should mimic browser (they did it for flash adn stuff, so why not for a simple field of text ??)

They could even have allowed us a kind of special URL like

fmp://field/fieldname, that would have simplifiedthe implementation for them.

Why I need this, because I want to let user create mailing list by filling just fields, and have them see the preview instaly.

no work around.

Plus, It would have allowed us to "work around" filemaker garphic innabilities. And present data much more esily.

Think like a nicely done portal for display, that you can export and publish to the web with a click.

Dumb developpers -)

Hi Genevieve,

I am afraid I do not get what you mean as well.

In fmp://field/fieldname, what is the difference between field and fieldname?

I am not aware of any web browser that can render text to html as you type it. As Roger said

Even in other html editors you must save the file first.

Would you consider that as a workaround as well?

As far as previewing- perhaps you can connect to yourself as an IWP client in some fashion to do this as well, but I have not played with that. I do not know if this would even qualify as a workaround- seems to be exactly what you are asking for in a fashion, although I still do not know why.

A larger issue is that rendering your mailing list in html and viewing through the web viewer seems like a long and un-needed workaround to just using portals or lists to view your mailing list in the first place.

Think like a nicely done portal for display, that you can export and publish to the web with a click.

I am still confused- I thought it only took me one click to get the cross tab reports.

-Raz

"every webbrowser on earth can render html text, they do not require a URL"

That is rubbish. Of course they require a url -- Universal Resource Locater - locates a file for the browser to parse whether it be local or web based -- all the web browser does is act as a parser. Have you ever pasted html code directly into a web browser? No, you've opened html files - and when you do open an html file - note the url of that.

What we are talking about is direct - for lack of a better word - rendering / processing / parsing of html code directly from a field rather than a document.

But besides all the ranting, its stuffs up my Filemaker File Associations - and when you un-install it, your even worse off.

That report stuff really is cool! This will save me loads of work I think.

While it is true that web browsers require a URL of some time, there are several applications that can preview html text without even creating a file. On a Mac these would be web editors, such as BBEdit, and some xml apps, like TestXSLT. Of course, you normally do save it as a file, but it is not required. TestXSLT in particular makes it clear that he is using the web kit which Safari is using. It's a free app and the source code is available.

So i don't think there is a great impediment, on the Mac at least, to FileMaker extending the capability of the web object viewer to render a FileMaker field. That doesn't mean they will however. Since I know nothing at all about "real" programming I couldn't guess how hard it would be to do. It would make things a little more confusing to users, in some ways, more choices. But it would sure be cool to be able to render an unstored calculation field as html without exporting a file, as it might not require a script.

The issue is that if the content is changed and the document is not well formed, the whole thing stuffs up - plus filemaker isn't a web page development program - so i don't see why having to export is such an issue - if you wan't live dev go to dreamweaver or a program more suited. Otherwise, it's one script step, and if your that desperate, use event script.

Well Genx, The point is precisely to not use HTML editor.

Standard users with absolutely no html knowledge should be able to create my mailing list just by filling fields, and have a preview of what they're doing.

You don't need a file to parse html, Golive offers live preview, and I know many app on mac that do so.

? No, you've opened html files - and when you do open an html file - note the url of that.

Excatly, so to ease the implementation of the function, I suggested fmp://field/fieldname

and off course, we could also store html code and have it rendered

Okay okay, i concede your right im wrong but two things:

a) It's still not that much of a let down as you seem to be making of it - sure it would be good - but they've just given us an ultimate tool.

THE FILE REFERENCES SCREW UP DAMNATION IT! Anyone else experience the problem on windows xp with FM Advanced, FM 8 and FM 8.5 installed - you can't change the default file reference back to advanced or 8 after installing 8.5?

And further i still maintain that your statement that every web browser can directly parse HTML without a URL - pointing to a file with .html extension indicating in the first place that that file is in fact an html file and thus should be processed as one - as false

I do understand that some html and text editors can preview the outcome, but I was basing my statement from the vantage of Dreamweaver MX. You can view the expected document in their viewer, but if you want to see what it really looks like in a browser, then you must save the file and have it opened in a browser.

This leads me to the point that the Web Viewer Object is an instance of IE on windows and Safari on Mac. It is not simply a rendering of field based text. The ability to open basically any type of document that has an extension or plugin for IE (on windows) is a leap forward. Beyond just being cool.

If you want a basic user to see their text or entries vieweds in the browser then script the output, export the field contents to a file and use the Set Web Viewer() script step.

I suppose there is no end to add on features we will want and of course nearly every advancement will be met with "It isn't enough". Thus we see new versions rolling out every x months. Not to mention it keeps us putting our quarters in their meter.

Upon further thought, I think now that those apps I mentioned (some of which use the web kit directly, just as FileMaker is doing), may be reading a temporary file. They are document-based apps. A FileMaker field is not and cannot be a temporary file of its own, therefore there is possibly no way FileMaker can just render a field as an html page, without some form of action such as export.

Genx,

You wrote:

THE FILE REFERENCES SCREW UP DAMNATION IT! Anyone else experience the problem on windows xp with FM Advanced, FM 8 and FM 8.5 installed - you can't change the default file reference back to advanced or 8 after installing 8.5?

Are you saying that when you open an .fp7 file it opens with 8.5 instead of 8.0? If this is the problem then it can be fixed.

Start > Control Panel > Folder Options

On the FILE TYPES tab scroll down till you get to FP7. Press the ADVANCED button. Highlight OPEN under the ACTIONS category. Press EDIT. In the "Application Used to Perform Action" field change that either manually or browse to the FM 8.0 executible.

That should fix the problem.

I am a "real" programmer sometimes (when not doing FileMaker) and it is certainly possible, and quite easy, to render something from memory instead of a file. In fact, this is exactly what happens when WebKit renders a file. It reads it into memory, then renders it. Rendering a string (like a FM text field) just involves skipping a step.

WebKit includes a few methods for this: loadHTMLString, loadData and others.

Now the interesting thing to me is that there's an extremely limited API for using WebKit through C, you pretty much have to use Cocoa/Obj-C. I was under the impression that FM was just a Carbon app, so I used the unix command 'nm' to find the symbols defined in the FileMaker executable.

It turns out that FM is using the Obj-C API for WebKit. They even subclass it with FMWebView and use a delegate called MyWebDelegate (I think they must have a pretty junior Cocoa programmer and he copied some Apple sample code). Then they wrap it in a C++ API for the rest of FM to use.

There appears to be a method called Platform_WebViewer.LoadSource(). So the functionality is already in the executable. My guess is that FileMaker uses this to display the "Loading..." text that appears in the Web Control before the page is loaded.

It might even be possible to write a plugin that calls this function.

Ted S, you'd think so, but it doesn't help. It's just a hell of a pain. Attempting to change it does nothing, now whenever i try to open an FM file directly from the FM file i get told "this action can only be performed on applications that exist". But then i can open FM advanced and the file from there.

Ive tried uninstalling, rebooting, system restore, etc. etc. And it's still giving me the same annoying message. I've reported it to FM support and they're "Investigating".

Yay - reading the post entries - i win ???

bummer.

I just tried to see if I could dynamically write to a web control by using "javascript:document.write('hello')" but it looks like the javascript: protocol doesn't work.

ftp: works though, as well as some others like rtsp: and help:, but feed: doesn't.

Storing your html code in a field and then dynamically exporting to a file so that it can be rendered in a web viewer is not that big of a deal. It's takes three fields and a three step script to do it and it doesn't require a set web viewer step if you store the file path in a field and set the web view to the value in that field. I have attached a sample file for people to look at. It works on the PC just fine but is having a problem on the Mac. Maybe someone here can figure that out.

-Mark

HTMl_Test.fp7.zip

Wow, Get( Desktop Path ) has a pretty serious bug.

It's returning a path that begins "/Macintosh HD/Users", which is completely wrong. The drive name should not be there. The fact that FM can read and write filepaths like that is just one bug covering another.

A correct path to the desktop would (usually) be like this:

"/Users/john/Desktop/" or "/Volumes/Machintosh HD/Users/john/Desktop"

I guess you can write a workaround for this, but I'd code it to work with correct paths too incase FileMaker fixes this.

Very cool! Is there a way to insert a filemaker field into straight HTML and then render it in the web viewer? For example if you wanted to have the field 'name' inserted in a specific place, is that possible?

Hi Alan I've read your post but I'm still not clear on what you are trying to acomplish. Glad you like my example file.

-Mark

Umm, what I think your refferring to is and has been a standard feature in FM for a while now (since at least 6)...

Substitute(YourHTMLContentFieldHere ; ["<>" ; YourFirstReplacementContentHere];

["<>" ; YourSecondReplacementContentHere])

Basically the function substitutes the text <> with a field or other text that you put where the words YourFirstReplacementContentHere is, and the same with the second tag etc. etc.

Ok great, I'll try that. Basically what I'm excited about and need to do is produce a report in html that has hyperlinks based on the content of a certain field. Right now (with dev 7) I have to export to html, then edit the code and do a find/replace to change those fields to hyperlinks based on it's value. It's sooo time consuming. With the web viewer and that report they showed in the included example it looks like this is possible to be automated.

I think XML export with a stylesheet is the best way to accomplish this - but XML/XSL has a steep learning curve.

I haven't played with the new toy yet, but it seems like this "browser" cannot extract plain text from HTML? If this is true, I guess parsing HTML will become the most FAQ on the forum.

XSL has a steep learning curve - talk about it, i was forced to conform to a company's data structure a month ago - god it was a pain. It took me two weeks, a video, two books and forum help to work it out. Even now i still have trouble working out the exact paths to nodes within the xml documents.

And in terms of the plain text thing - couldn't you just try using GetAsText()

EDIT: Nvm, i just realized its an object not a field.

Edited July 14, 200619 yr by Guest

I would expect GetAsText(HTML) to return exactly what was input into it.

I just submitted a bug on Get ( DesktopPath ).

Mark, I changed HTML Test so that it fixes the path on Macs. It's annoying because FM won't accept correct paths at all for operations like export.

HTMl_Test.fp7.zip

Weird, On the HTML test application posted, my web viewer says file not found, even though I see the apple.html file on my desktop. The path seems right to the desktop. Any ideas?

Mac OS X Panther

Which version are you using? The original, or the fixed one?

Hey thanks for fixing the code. Yea I don't know what's up with FileMaker on the Mac with file paths. You would think they could get things on work on their "native platform" so to speak. On my Mac (Dual 867 10.3.9) the web viewer still didn't activate the html for some reason. This is not something I need to do but I thought I would whip up the example file as a proof of concept anyway.

-Mark

The problem is that OS X is not FileMaker's native platform. They still think like we're all on Classic Macs, where colons are the path separators and all paths start with the drive name.

I would argue that FileMaker considered the options, and made a good choice.

Myay, me too.

I'm using the fixed version. Not sure why this is happening. Can someone describe their file path to me. Maybe I'm missing a slash or something.

Thanks!

What do you get when you do Get Info on the Desktop folder? Or run "get path to desktop" in Applescript?

Fenton, how did they make a good choice? They're returning the wrong path for the desktop. It's not a valid OS X path.

The Get Info box says the path to my desktop folder is:

/Users/spankalee