{"id":173,"date":"2007-09-22T05:06:00","date_gmt":"2007-09-22T05:06:00","guid":{"rendered":"\/lisa\/post\/2007\/09\/22\/MaxHeightAvailable-Rules.aspx"},"modified":"2007-09-22T05:06:00","modified_gmt":"2007-09-22T05:06:00","slug":"maxheightavailable-rules","status":"publish","type":"post","link":"https:\/\/spacefold.com\/lisa\/2007\/09\/22\/maxheightavailable-rules\/","title":{"rendered":"MaxHeightAvailable Rules"},"content":{"rendered":"<p>\nThis one is for you VFP reporting folks, although the subject comes to mind by way of a SQL Server reporting conundrum <a href=\"http:\/\/forums.microsoft.com\/MSDN\/ShowPost.aspx?PostID=2143572&amp;SiteID=1\" target=\"_blank\" title=\"how to handle long text in SQL Server RS\" rel=\"noopener\">in the forums recently<\/a>.\n<\/p>\n<p>\nThe problem-to-solve is one of those Reporting Convergence things you&#39;ll see no matter where, and how, you report:\n<\/p>\n<h5>How do you handle stretching&nbsp;content that is longer than a single page in length? <\/h5>\n<p>\n<br \/>\nThe interesting point, in this case, is not how similar things are, but how the resolution in RS will contrast with what you can do in VFP in&nbsp;similar scenarios.\n<\/p>\n<p>\nThe original layout in the recent thread looked like this:\n<\/p>\n<table border=\"0\" width=\"60%\" align=\"center\">\n<tbody>\n<tr bgcolor=\"#ff0000\">\n<td bgcolor=\"#00557d\"><font color=\"#ffffff\">Page Header<\/font><\/td>\n<\/tr>\n<tr bgcolor=\"#ffff00\">\n<td bgcolor=\"#00699b\"><font color=\"#ffffff\">Table Header<\/font><\/td>\n<\/tr>\n<tr bgcolor=\"#008000\">\n<td bgcolor=\"#7997ae\"><font color=\"#ffffff\">=&quot;<\/font><font color=\"#ffffff\">Group Header: &quot; &amp; Fields!Field1.Value<\/font><\/td>\n<\/tr>\n<tr bgcolor=\"#f0f8ff\">\n<td><font color=\"#7997ae\">=&quot;Value of another field:&quot; &amp; Fields!Field2.Value<\/font><\/td>\n<\/tr>\n<tr bgcolor=\"#f0f8ff\">\n<td bgcolor=\"#f0f8ff\">=Fields!LongField.Value<\/td>\n<\/tr>\n<tr bgcolor=\"#008000\">\n<td bgcolor=\"#7997ae\"><font color=\"#ffffff\">=&quot;Group Footer: &quot; &amp; Fields!Field1.Value<\/font><\/td>\n<\/tr>\n<tr bgcolor=\"#ffff00\">\n<td bgcolor=\"#00699b\"><font color=\"#ffffff\">Table Footer<\/font><\/td>\n<\/tr>\n<tr bgcolor=\"#ff0000\">\n<td bgcolor=\"#00557d\"><font color=\"#ffffff\">Page Footer<\/font><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>\n<br \/>\nThe long text field you see in this detail band always moved to the next page, leaving a large block of empty space in the layout where you would have expected the long text to start displaying. After some experimenting with why this was causing a page break on every page, I determined that the rules in RS are something like this:\n<\/p>\n<blockquote>\n<p align=\"left\">\n\tWhen a text field requires more height than is left on the page, it is pushed to the next page.&nbsp; However, when a text field requires more height than the full-available height on a page (ie it is the first thing on that page), it is not pushed to the next page, because this would happen infinitely. The thing would never appear and the report would never finish.\n\t<\/p>\n<\/blockquote>\n<p>\nTherefore, the resolution in RS looks something like this (you can look at the code, which isn&#39;t a big deal, <a href=\"http:\/\/forums.microsoft.com\/MSDN\/ShowPost.aspx?PostID=2143572&amp;SiteID=1\" target=\"_blank\" title=\"same thread ref as above\" rel=\"noopener\">in that thread<\/a>). You split the long field into a section which has room to appear on the &quot;proper&quot; page and move the rest of the content to a separate element. Because this separate element is now the first thing on the next page, it is properly rendered, no matter how many pages it may take to do so, on subsequent pages.&nbsp; The &quot;continued&quot; message you see here, between the two portions of the long field contents, is optional:\n<\/p>\n<table border=\"0\" width=\"60%\" align=\"center\">\n<tbody>\n<tr bgcolor=\"#ff0000\">\n<td bgcolor=\"#00557d\"><font color=\"#ffffff\">Page Header<\/font><\/td>\n<\/tr>\n<tr bgcolor=\"#ffff00\">\n<td bgcolor=\"#0073aa\"><font color=\"#ffffff\">Table Header<\/font><\/td>\n<\/tr>\n<tr bgcolor=\"#008000\">\n<td bgcolor=\"#7997ae\"><font color=\"#ffffff\">=&quot;<\/font><font color=\"#ffffff\">Group Header: &quot; &amp; Fields!Field1.Value<\/font><\/td>\n<\/tr>\n<tr bgcolor=\"#f0f8ff\">\n<td bgcolor=\"#f0f8ff\"><font color=\"#7997ae\">=&quot;Value of another field:&quot; &amp; Fields!Field2.Value<\/font><\/td>\n<\/tr>\n<tr bgcolor=\"#f0f8ff\">\n<td bgcolor=\"#f0f8ff\">=Code.SplitLongField(Fields!LongField.Value,1) <\/td>\n<\/tr>\n<tr bgcolor=\"#ffa500\">\n<td bgcolor=\"#f0f8ff\">=Code.GetContinuedMessage(Fields!LongField.Value)<\/td>\n<\/tr>\n<tr bgcolor=\"#f0f8ff\">\n<td bgcolor=\"#f0f8ff\">=Code.SplitLongField(Fields!LongField.Value,2) <\/td>\n<\/tr>\n<tr bgcolor=\"#008000\">\n<td bgcolor=\"#7997ae\"><font color=\"#ffffff\">=&quot;Group Footer: &quot; &amp; Fields!Field1.Value<\/font><\/td>\n<\/tr>\n<tr bgcolor=\"#ffff00\">\n<td bgcolor=\"#00699b\"><font color=\"#ffffff\">Table Footer<\/font><\/td>\n<\/tr>\n<tr bgcolor=\"#ff0000\">\n<td bgcolor=\"#00557d\"><font color=\"#ffffff\">Page Footer<\/font><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<h4>\nContrast with the VFP 9 Reporting System<\/h4>\n<p>\n<br \/>\nIf you use VFP reporting, you know that we don&#39;t need to worry about this for stretching text. The code splitting the&nbsp;text into &quot;what will fit on the current page&quot; and &quot;what&#39;s left&quot; is handled internally by the VFP report engine.&nbsp; It might not be&nbsp;handled perfectly all the time, but it&#39;s handled less simplistically.&nbsp;\n<\/p>\n<p>\nIn fact in writing the code for this resolution, I basically did in VB code what I thought the RS renderers could potentially do themselves.&nbsp; Maybe they don&#39;t because it would cause even more havoc and differences between renderers, as each output format struggled with its own page layout requirements.\n<\/p>\n<p>\nBut there <em>is<\/em> an interesting parallel, with instructive differences,&nbsp;between the scenario above and the ReportListener&#39;s <a href=\"http:\/\/msdn2.microsoft.com\/en-us\/library\/ms996949(vs.80)\/\" target=\"_blank\" title=\"ReportListener.AdjustObjectSize docs\" rel=\"noopener\">AdjustObjectSize<\/a>&nbsp;feature for stretching images and shapes.\n<\/p>\n<p>\nAs you probably know, in the ReportListener.AdjustObjectSize&nbsp;event you can consult the MaxHeightAvailable member of the properties object to see how much usable space there is on the rest of the page.&nbsp; By &quot;usable&quot; I mean that this value does not include space&nbsp;in the&nbsp;remaining page&nbsp;length&nbsp;that must be substracted\/reserved for footer elements. &nbsp;(I&#39;m not going to repeat the docs information here, because it&#39;s expressed properly there already; this post does not constitute any sort of correction.)\n<\/p>\n<p>\nThis feature effectively gives us a chance to decide what to do when you want to render dynamic content that is not going to fit on the page.&nbsp; Just as I could write some limited VB code to do what I thought the RS engine might do, you have the ability to make pretty much the same calculation &#8212; with whatever rules suit you, in Xbase code&nbsp;&#8212; that report engines&nbsp;all have to make in this situation internally, and&nbsp;that&nbsp;report engines&nbsp;often hide from you with almost-as-often annoying results.\n<\/p>\n<h4>With great power comes great responsibility<\/h4>\n<p>\n<br \/>\nRemember: The RS engine chooses what to do to avoid a possible infinite push-down loop.&nbsp; Its choice is as follows: push down once if an item does not fit. Then, on the next page, if the item <em>still<\/em> won&#39;t fit even though it has the full usable page to deal with, unilaterally choose a pagination method for the item&#39;s content to break it up between pages.\n<\/p>\n<p>\nIn VFP, it&#39;s up to you.&nbsp; You get MaxHeightAvailable to help you make your decision about what Height should be used.&nbsp; You can set it too high for the remaining page space, forcing a page break if you want.\n<\/p>\n<p>\nAlternatively, if you set Height lower,&nbsp;you can&nbsp;make the thing fit on the current page.&nbsp; You can then use the Reattempt member value of the properties object, on the next page, to decide what you want to do there.&nbsp; If you do not pay attention to Reattempt, and again set Height to a value that still won&#39;t fit, you can in fact cause an infinite push-down loop to occur.\n<\/p>\n<p>\nWhen you think about what you might do with this capability, remember that the shape or image layout element might just be a placeholder for other custom content (RTF, anyone?) that you are shoehorning into this report.\n<\/p>\n<p class=\"NB\">\nRather than post an example here, I&#39;m going to ask you to check the code that gets generated for an image or rectangle when you set Dynamic conditions for&nbsp;its Height or Width in SP2. <\/p>\n<p>Press the <strong>Script<\/strong>&#8230; button from the <strong>Dynamics<\/strong> tab in the ReportBuilder Properties dialog, and don&#39;t forget that you can <strong>Code Zoom<\/strong> from there for a closer look.&nbsp; You may have to change your preferences for .TXT files to get syntax coloring in the Code Zoom dialog.<\/p>\n<p>It&#39;s worthwhile getting used to doing this, and besides, you&#39;ll see that the code there observes other niceties, such as the overall max allowable values, which you&#39;ll also find listed in FOXPRO_REPORTING.H: <\/p>\n<p><font face=\"Courier New\">#<font color=\"#0000ff\">DEFINE <\/font>FRX_RUNTIME_LAYOUT_DIMENSION_LIMIT 64000<\/font><\/p>\n<p>There&#39;s also helpful information in editboxes within the ReportBuilder&nbsp;dialogs.\n<\/p>\n<p>\nAnd there you have it.\n<\/p>\n<h5>You can hunt your own game and bring it to the table, or you can shoot yourself in the foot. <\/h5>\n<p>\n<br \/>\nIsn&#39;t that, yea verily,&nbsp;the essence of the VFP way?<\/p>\n","protected":false},"excerpt":{"rendered":"<p>This one is for you VFP reporting folks, although the subject comes to mind by way of a SQL Server reporting conundrum in the forums recently. The problem-to-solve is one of those Reporting Convergence things you&#39;ll see no matter where, and how, you report: How do you handle stretching&nbsp;content that is longer than a single<a class=\"more-link\" href=\"https:\/\/spacefold.com\/lisa\/2007\/09\/22\/maxheightavailable-rules\/\">Read more<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5,9],"tags":[],"class_list":["post-173","post","type-post","status-publish","format-standard","hentry","category-reporting","category-visual-foxpro"],"_links":{"self":[{"href":"https:\/\/spacefold.com\/lisa\/wp-json\/wp\/v2\/posts\/173","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/spacefold.com\/lisa\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/spacefold.com\/lisa\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/spacefold.com\/lisa\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/spacefold.com\/lisa\/wp-json\/wp\/v2\/comments?post=173"}],"version-history":[{"count":0,"href":"https:\/\/spacefold.com\/lisa\/wp-json\/wp\/v2\/posts\/173\/revisions"}],"wp:attachment":[{"href":"https:\/\/spacefold.com\/lisa\/wp-json\/wp\/v2\/media?parent=173"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/spacefold.com\/lisa\/wp-json\/wp\/v2\/categories?post=173"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/spacefold.com\/lisa\/wp-json\/wp\/v2\/tags?post=173"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}