webviewer background image from filemaker container field

Darren

unread,

Mar 22, 2009, 10:09:06 AM3/22/09

to

I am using a webviewer to display data on a layout. The data is a
record count such as "Record 1 of 50 (50 Total)"

I have gotten that working correctly, however since a webpage renders
the background as white by default, the background of this webviewer
is white. This does not look so good when placed on top of my nice
gradient filled status bar at the bottom of the application.

Setting the fill of the webviewer to transparent does not work since
the rendered contents of the webviewer is essentially a webpage with a
white background.

The solution would be to use a background image of a gradient to match
my gradient on the toolbar or perhaps to use a transparent background
gif.

Question is, how would one get a webviewer to use a background gif
that is stored in filemaker in a container field?

Darren Burgess

Ursus

unread,

Mar 23, 2009, 7:28:34 AM3/23/09

to

"Darren" <darrenbu...@gmail.com> schreef in bericht
news:ca2b334f-63f1-4519...@g19g2000yql.googlegroups.com...

Darren,

First I would like to know the reasoning behind using a web object. Any
calculated text field could display the text you need. Make it transparent
and use a background. Even a calculated backgroundcolor is possible with the
conditional format.

If you really want to stick with the webobject you have to look into inline
calculation.

a couple of examples: make a webobject and set its calculation to:
"data:text/html,<H1>Hello World!</H1>"
switch to browse mode an you'll see the result. This could contain text and
images like a normal html file

You can even create small inline images like this: (a small smiley)
"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAA4AAAAOCAMAAAAolt3jAAAABGdBTUEAAK/INwWK6QAAABl0RVh0U29mdHdhcmUAQWRvYmUgSW1hZ2VSZWFkeXHJZTwAAAERUExURf/sgv/mZNWiKJ+fn//xn82UHP/1vP/52Q8PD//+9fziYP/yqf/ujP/zsvuhLv/tg29vb/ujM/27ceG2OuG2OfulMPukMtDBVvuiLP/seejCRP/jYbCdQ/uiMv27b/ujNKCOPZCBN+zISSAdDe/v7zAsE/uiM//vlfTVVeS8P7+yaf/58/DWW4+Pj//iYPy2NsCwTvDbYaCPPU9PT//48F9fX/uhMf/iYUA5GIByMfyzM/y3aJCEOv/47//sau/lrOjCRf/27MWHEv25bODOWv2/d7CiR/21NfukNPulNP/raf2+dnBkK/24Of24af/qZ/uiMPukM/uhLPukMP/jYv/lY//kYv/pZ//oZgAAAP///9XL2twAAADdSURBVHjaYtB2leULAAM+MyFbgABi8LbSM7JU0JGx8FE013cGCCAGQWnxSGU3fxcDG1XxUA+AAGKQCDPUsueNiFDnZQhnFAUIIIagkHBOZmYGBmZdzvDQYIAAAnL5ozgiubk5IlX4Q4MBAgjIlYwSMGVhETCOkgwNBgggkGIedraICDZ2HqBigAACcSMgQArIBQggEJdJA8RTYgVyAQIIaFE4FxOTiAirExfQIoAAYlALsQsPdxAW1gwP92L0BAggBiH3sNAwMAgN87UGCCAGEzl5sUAwEBP0cwQIMACMqSpH1j9VNgAAAABJRU5ErkJggg=="

ofcourse you could stick the text into a textfield, or calculated field,
then transfer that to your webobject

--
Keep well / Hou je goed

Ursus

d-42

unread,

Mar 23, 2009, 3:33:04 PM3/23/09

to

On Mar 23, 4:28 am, "Ursus" <ursus.k...@ziggo.nl> wrote:
> "Darren" <darrenburgess1...@gmail.com> schreef in berichtnews:ca2b334f-63f1-4519...@g19g2000yql.googlegroups.com...

>
>
>
> >I am using a webviewer to display data on a layout. The data is a
> > record count such as "Record 1 of 50 (50 Total)"
>

> First I would like to know the reasoning behind using a web object..

Seconded. Ursus is absolutely right.
I can't fathom why you'd want to use a web viewer object for this.

Darren

unread,

Mar 24, 2009, 12:35:46 PM3/24/09

to

A agree that using a webviewer may seem to be perhaps overkill when a
calc field could do the job.

This is why I am using a webviewer
1. I want to learn how to use the viewer to display data
2. using a webviewer to display data forgoes the necessity of
creating a field.
3. I like the elegance and simplicity of using the interface/layout
to create the information.

I have been listening to the filemakertalk podcast and the suggestion
was that webviewers save on application overhead by keeping interface
info (like a record count) out of the schema of the database.

Clearly, it may be debatable how much over head a field such as a
record count really adds to database. Probably not much, and I can
see the value of thinking in terms of reducing the number of fields in
the tables.

Darren Burgess

Grip

unread,

Mar 24, 2009, 12:53:22 PM3/24/09

to

On Mar 24, 10:35 am, Darren <darrenburgess1...@gmail.com> wrote:
> A agree that using a webviewer may seem to be perhaps overkill when a
> calc field could do the job.
>
> This is why I am using a webviewer
> 1. I want to learn how to use the viewer to display data
> 2. using a webviewer to display data forgoes the necessity of
> creating a field.
> 3. I like the elegance and simplicity of using the interface/layout
> to create the information.
>
> I have been listening to the filemakertalk podcast and the suggestion
> was that webviewers save on application overhead by keeping interface
> info (like a record count) out of the schema of the database.
>
> Clearly, it may be debatable how much over head a field such as a
> record count really adds to database. Probably not much, and I can
> see the value of thinking in terms of reducing the number of fields in
> the tables.
>

I can understand that reasoning. But using a web viewer is more of a
trick than an intended method. And as such, there are limitations,
like the one you're running into. And now you need a field to hold
the background gradient.

You don't state what version of FM you're using, but if it's an
Advanced version, you can create a custom function that will parse
whatever you feed it into HTML. Could be handy here.

G

Darren

unread,

Mar 24, 2009, 2:11:22 PM3/24/09

to

Ok, here is the custom function code that is called in the webviewer.
I used http://www.dopiaza.org/tools/datauri/index.php do generate the
base 64 code for the gradient gif image so that the image can be
embedded directly in the webviewer. The image is a one pixel wide by
about 40 tall grey gradient. In order to clean up this code, I would
probably put the base64 data in its own CF.

custom function = webviewer.recordcount

"data:text/html,<html><head>
<style>
body { border: 0; margin: 0; font-family: \"Lucida Grande\",
Tahoma; }
</style>

<font size = 1>
<div align = \"right\">" &
display.recordCount &
"</head></div></body></html>"

The CF display.recordCount is as follows:

Case ( Get ( WindowMode ) = 1 ;
"Requests: " & Get ( RequestCount ) ;
"Record " & Get ( RecordNumber ) & " of " & Get ( FoundCount ) &
" (" & Get ( TotalRecordCount ) & " total)" )

Thanks for the input.

Darren

unread,

Mar 24, 2009, 2:19:36 PM3/24/09

to

seems this code only works in OS X FMPA 10. FMPA 9 in windows XP
displays just a white background.

As you were saying, there are limitations (for which there may be a
solution)

darren

d-42

unread,

Mar 24, 2009, 3:24:25 PM3/24/09

to

On Mar 24, 9:35 am, Darren <darrenburgess1...@gmail.com> wrote:
> A agree that using a webviewer may seem to be perhaps overkill when a
> calc field could do the job.
>
> This is why I am using a webviewer
> 1. I want to learn how to use the viewer to display data

Ok. I can't fault that.

> 2. using a webviewer to display data forgoes the necessity of
> creating a field.

Ok. But that's kind of like poking your eyes out to save money on
contact lenses; and then hiring someone to escort you around because
you are now blind.

> 3. I like the elegance and simplicity of using the interface/layout
> to create the information.

It is not elegant or simple the moment you factor in how a webviewer
actually works.

On Windows, for example, with FM9 (I haven't re-tested with FM10 yet),
it uses the built in Trident rendering engine for the webviewer, which
in FM9 couldn't support more than several hundred characters in the
URI, so when you pass a data: URI, it writes out a temporary file to
the system temp folder (always, regardless of how much data you pass
it), and then passes it to the trident engine to render, and then
passes the result back to FM to display.

So, every time it updates the display of the field, it exports a
file...and so on. Its completely ridiculous. On OSX, it uses safari
which doesn't have URI limitation so low, so at least it doesn't write
out a temporary file, but again, its completely ridiculous to call
Safari to perform and display simple text concatenation.

In nearly any situation, the webviewer is the most expensive option.
In MANY cases its well worth it, because you can get precisely the
layout and format you want. But it was designed to let you embed web
pages in filemaker. That's it. Resourceful developers have used it to
build and embed web pages on the fly to achieve dynamic data display
that simply wasn't previously possible (and I fully support, and even
do it myself) but its important to really understand the big picture,
including how it works.

> I have been listening to the filemakertalk podcast and the suggestion
> was that webviewers save on application overhead by keeping interface
> info (like a record count) out of the schema of the database.

There's never a shortage of lousy advice on the internet.
And the quality of advice in books and formal filemaker education is
pretty hit and miss too in my opinion. Some of it is really good...
some of it is just awful.

> Clearly, it may be debatable how much over head a field such as a
> record count really adds to database. Probably not much, and I can
> see the value of thinking in terms of reducing the number of fields in
> the tables.

No. There is no value in reducing the number of UNSTORED CALCULATION
fields, except to the extent that it reduces a bit of filemaker UI
clutter.

Unstored calculations add essentially NO OVERHEAD to the database.
They are kind of ugly in terms of cluttering up your schema. Most good
filemaker developers use naming conventions to address this... my
unstored calcs all start with zc_, my summary fields are zs_, zg_ for
globals, etc.

This sticks them at the bottom of the list out of the way, and
immediately identifies them as unstored calcs / sumary fields.

Fields that exist strictly for UI purposes like filter pivots, etc are
also named with a convention.

Let me say it again: An unstored calculation creates virtually no
overhead. It doesn't create and allocate storage for a field for every
record in the database. Its just a calculation definition ...its
really no different than a custom function scoped to a particular
table occurance in the relationship graph.

Doing contortions to reduce schema clutter in filemaker is demented.
As a SQL pro coming into Filemaker, it took me a while to come to
grips with filemaker's way of doing things too, especially coming to
grips with things like schema clutter.

What you should do is come the the realization that unstored
calculations at the 'database theory' level aren't really part of the
database table as it would be defined in another database system. They
don't affect normalization. They aren't adding overhead. They aren't
even evaluated until they are explicitly referenced.

I've advocated in the past that FM change the UI, to separate the
actual "real database schema fields" from the unstored clutter defined
on them (including globals, summaries, and unstored calculations).
This would let SQL guys from the wider world be more comfortable with
Filemaker... they wouldn't feel like they were bloating their database
with extraneous UI fields. But in reality, that's the only benefit...
making SQL guys more comfortable. Its just as easy for us SQL guys to
adapt to Filemaker and understand that unstored calculations, globals,
and summaries really aren't part of the database schema in the
'traditional sense', anyway. And there appearance in filemaker as part
of the 'table' defnition is really just Filemaker's UI.

-regards,
Dave

lisa...@gmail.com

unread,

Mar 30, 2013, 10:17:51 PM3/30/13

to

The User wants to know if there is a way to get a transparent web viewer window.
I would like to know this as well.