Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Print to HTML-file vertical lines do not show
Message
 
 
À
28/04/2007 15:52:51
Information générale
Forum:
Visual FoxPro
Catégorie:
Gestionnaire de rapports & Rapports
Divers
Thread ID:
01220753
Message ID:
01220858
Vues:
22

no vertical lines, funny it is not stated anywhere in neither MS help nor Lisa's perfect masterpiece.


Excuse me. I don't exactly know what you are talking about here, but:

Sarcasam unnecessary. Colin was trying to help you.

1. Vertical lines certainly do show in many, many reports, so there was certainly no need to state in the docs that they aren't supported. They're not guaranteed to show all the time (in every report and every width line), but that's because they're being created with an HTML construct that isn't a vertical line, since a vertical line contruct doesn't exist in HTML. In point of fact, if memory serves, we use a SPAN with appropriate dimensions and we try -- as much as possible -- to translate VFP line types or pen patterns to appropriate HTML equivalents.

You might try experimenting a bit or even asking a question such as "why don't THESE lines show in MY report?" rather than jumping to conclusions.

Yes I mean the scrollbars, dont you consider it being a bug when scrollbars, unwanted, show up in either the visual output or the hardcopy output? No difference when using the SP2 the 3 report*.app's


2. The scrollbars are there because we use TEXTAREAs by default for stretching text. And no this is absolutely not a bug. It is by design because otherwise, given the HTML linespacing difference, there is a good chance that stretching text with CRLF's will be truncated.

It is also by design that, if you know for a fact that your content will *not* be truncated in a given report, the way you have set up the dimensions of your layout controls, your line spacing, your font, and (most importantly) any hard line breaks contained in your content, you can easily change the way this works. IOW, you can tell the standard processor to use DIVs instead of TEXTAREAs for stretching text. And this was true both in RTM and SP1 as well as SP2.

What Colin was referring to is that, in SP2, we made it easier for you to find this functionality and use it, not that the ability to turn off the textareas is new in SP2.

You will find the ability to bind in the non-default behavior in Document Properties. (HTML.TextAreasOff). Textareas are still default in SP2, because that is still the correct default.

However, if you would like to turn off the textareas and *not* bind in the behavior to a report, we have made that a bit easier to do in SP2 as well. It was always possible; now it is easier. There is a new adjustXSLTParameter so that you can perform this task in one line of code instead of three .

So, in general you don't need to "try to construct a HTMLconverter to correct the unwanted behaviors". However please go ahead and do it if you feel like doing it. You might want to start by investigating *how* we do it and seeing in what way you want to improve it. Whether you want to start by doing that or by building from scratch, perhaps you'll learn something in the process.

For example, you might be able to answer your own question about why the textareas show scrollbars in some browsers and not others and how to change that behavior -- even if you decide you do want to retain the textareas, once you understand why they are there. How individual browsers treat the styling of TEXTAREAs, is a different question than "should I have TEXTAREAs". There's a bit of latitude in the standard, in how the CSS overflow property is to be interpreted, if I recall, and even if there weren't latitude, different browsers still render style attributes differently.

The ability to make style tweaks for this type of thing, while in your control previously, is also something that we have made easier to do in SP2. Please see Document Properties (HTML.CSSFile) and two corresponding Advanced Properties for Fields regarding the setting of HTML.CSSClass for individual objects.

3. No matter what you think about what I do or write or what Colin does or writes, you have been given considerable help to move forward.

I am not even going to say "I'm sorry that you don't think it's ENOUGH help". I'm not sorry. Going forward, if you want to do this stuff, you do have to learn things. If you are going to tell your customers that you provide HTML output, I think you would have to learn more -- about browsers, CSS, and several other things -- no matter what we did or what Microsoft provided to you.

Good luck.

>L<
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform