Familiar situation?  Post-Q&A translation = LOTS of F000* elements.  It'd be a PITA to name all these buggers in Q&A's Set Field Names because most of them are going bye-bye when I re-program other elements in Sesame.  But until that re-programming happens (and, in fact, to allow that re-programmiong to happen) I need to muck with them.

So, advice?  Best/easiest/fastest way to identify and jump to, say, F0058 on a form with dozens of F000's? 

Ray,

That second idea sounds great.  But I'm not too familiar with Sesame's Mass Update procedure, and have no idea what command I would use to have element labels change to their names.  A bit more hand-holding, please?

Woo hoo!  Thanks Ray!  Take a raise out of Petty Cash and tell them Captain Infinity said it was OK!

New things you have taught me (or started me towards learning):
* Max 1
* Extend Mode (I'm going to have to read up on this as I have no idea what it is, but it looks very useful)
* Printing commands hiding under Record commands.

I'll have to play around with the printout setting a bit, because this "form" was actually 10 pages of Q&A, so when it prints formatted for a single page it all becomes a blur of gray down the middle of the paper.  But just seeing the element names on the screen is very helpful.

Thanks again!

(By the way, before I read your detailed answer I was playing around with

Label(ThisElement,@Label(ThisElement)) 

in the Global Code section of the Mass Updater.  It didn't do a darned thing but the program editor was happy with it.  Heh!

Quote:


There we go!  Thanks again.

Quote:


Well super, I succeeded at something completely pointless.  Just one more thing to add to the list.  YAY!

Hello Scott,

In the future there is this little thing called Version 2.0 which allows you to print your form onto multiple pages in either direction, right from Sesame. So you could print your form on say 6 pages, two across and three down.

-Ray

Hi Scott...

I use Firefox extensively with all of my accounts. 

Would be curious to see what is happening.  Any chance you can share the html file that is not printing properly? 

I would like to check that out here to see the results you mention.

See:
http://captaininfinity.us/workform.htm

I've fiddled with my page settings in numerous ways, and all I can get is a single page to print.  When I look at the form in preview, the fields and labels continue past the bottom of the imaged page, hanging in mid-air, for just a line or two.  Then the preview stops.

Let me know what you see, thanks.

Quote:

I know, I was just teasing you. 

Quote:

Thanks Ray, that works well.

Quote:

Sigh.

We do appear to have a minor issue with closing the HEAD tag in the wrong place, but the issues reported by the validators are not causing the problem. Most of the validation errors are not meaningful. For example, we don't have an ACTION tag on the Form, but the Form is not intended to submit and has no script (action) it can run. Most of the errors are related to TEXTAREA attributes, which are being specified as part of the style instead of using the older HTML syntax.

The printing problem is caused by the fact that, while Firefox is rendering the page on screen just fine, it's print engine is not managing to translate to pages. This is because,in order to make it look like your Form, everything uses absolute positioning. The absolute positioning creates coordinates that are much longer than a page. It looks fine on screen, but Firefox can't figure out how to get it onto paper.

Thanks for making that page "valid" Ray.  Can you send me the "valid" page?  I will submit this as a bug to Firefox.  Response there is not as quick as here (nothing is), but is much better than submitting for a change to MSIE.  I do know there will be a response.  I have had two earlier bugs corrected by them.

And thanks to Erika for the explanation about the text area of coding errors.  There definitely is a difference between a Sesame form and a web page form that needs a Submit, etc., so much less code is needed.

FYI,

I just ran the validator on www.yahoo.com, and it came up with "Result: Failed validation, 295 errors".

www.google.com produced 50 errors. www.mozilla.com produced 4 errors.

Almost every page I tested produced errors, with the exception of their own site validator.w3.org (of course), and www.microsoft.com.

I even built a new page from scratch in FrontPage 2002 with very little info in it. I did not construct the HTML, I let the FrontPage interface do that for me, and that produced 2 errors.

I guess Sesame is not alone, most pages do seem to have errors.

Quote:


Another Quote:


I would not recommend that this be reported as a bug to Mozilla/Firefox. There is, as far as I can tell, no determinable "correct" behavior when attempting to print fields at absolute coordinates that are beyond arbitrary page coordinates. In other words, what firefox is doing is just as correct as what IE is doing - even if we don't like it.

The problem firefox and IE has to beat is that HTML/CSS is built to use an arbitrary resolution device (so that a browser, or a page of paper can each be addressed in scale without reference to the hardware capabilities of the device used to render the HTML). So, for example, lets say that IE has determined that the end of a page is at a Y coordinate of 1000. And further, the CSS dictates that a field is to be placed at a coordinate of 1100. IE, would then cause that field to be placed on a subsequent page at a Y coordinate of 100. But what would then be the behavior if a larger piece of paper? Would IE increase the page break to 2000, or would everything simply print larger?

Firefox fares no better. They have determined that the behavior of rendering that exceeds an arbitrary distance should be undetermined. The spec supports this, basically telling browser makers to do as they please unless otherwise specified. So, for example, a browser could determine that all coordinates fall within a single page, and scale accordingly.

Basically, all three approaches: print multiple pages (IE); fail if the coordinate exceed unspecified boundaries (Mozilla/Firefox); or scale so that the page encompasses all specified coordinates, are essentially "correct" behavior.

CSS will eventually take care of this. Print style sheets that determine this behavior are already in the next CSS spec, and are partially implemented in some browsers.

If you prefer the printing behavior of IE, and you are using a Windows based computer, the Print To HTML command does produce a HTML file that can be printed without using either browser by right clicking on that file and selecting "Print" from the right click menu.

Hello Scott,

Have a look at the SESAME_PRINT_PREVIEW_COMMAND Enviroment Variable on page 463 of the Sesame 1.1 User's Guide.

-Ray

However: it's working for my Reports - the previews are opening in IE.

Curious thing, though.  When I run a preview, a command window opens, then IE opens and shows the report.  Meanwhile, the command window is just a black screen (because it's shelling out to IE?  I dunno.)  Also meanwhile, my Sesame window is completely blank, staying that way until I close IE, whereupon the command window closes and the Sesame interface returns.

Is this normal behavior?

No problem; you taught me something new and that's always good.  I'll certainly make use of it somewhere, somehow, down the line.

But now you've got me thinking...can a report be crafted that will do what Mass Update -> Print Form to HTML is trying to do?