I send you a couple of patch files. (Developers with active RB 20.01 license can email support@ and request the patch).
The ShiftRelativeTo feature was supposed to be disabled for objects inside a container, such as a Region or Table Cell. For RB 20.01 some logic was added to better enforce this rule.
However, it has come to light that adding validation breaks existing reports, this was not the intent. Somehow the existing reports, though configured incorrectly produce an ok result.
Best regards,
Nard Moseley Digital Metaphors www.digital-metaphors.com
what's the idea behind this intendtion? It was nice to pack a few shifting memos into a region to keep them together or disable them all for a specific situation. How should we change old reports?
You said that "Somehow the existing reports, though configured incorrectly produce an ok result."
So, if it worked ok for years, it seems that such restriction has no apparent purpose and maybe should not even exist. Or are any known case that the previous behavior would fail?
A customer submitted a case where a region contained only a memo. The memo ShiftRelativeTo referenced a subreport above. But the Region ShiftRelativeTo was empty. That's an incorrect configuration, but it produced an ok result.
Via email you stated you have a case where two memos inside a region and memoB ShiftRelativeTo memoA. Looks like that's ok.
Best regards,
Nard Moseley Digital Metaphors www.digital-metaphors.com
Comments
I have the same issue.
For Memos inside of Regions the property ShiftRelativeTo cannot be set to another Memo inside the same Region. In RB 19.x this was possible.
I send you a couple of patch files. (Developers with active RB 20.01 license can email support@ and request the patch).
The ShiftRelativeTo feature was supposed to be disabled for objects inside a container, such as a Region or Table Cell. For RB 20.01 some logic was added to better enforce this rule.
However, it has come to light that adding validation breaks existing reports, this was not the intent. Somehow the existing reports, though configured incorrectly produce an ok result.
Best regards,
Nard Moseley
Digital Metaphors
www.digital-metaphors.com
what's the idea behind this intendtion? It was nice to pack a few shifting memos into a region to keep them together or disable them all for a specific situation.
How should we change old reports?
Best regards,
Frank Liebig
When Memo is inside a Region, use Region.ShiftRelativeTo.
Best regards,
Nard Moseley
Digital Metaphors
www.digital-metaphors.com
You said that "Somehow the existing reports, though configured incorrectly produce an ok result."
So, if it worked ok for years, it seems that such restriction has no apparent purpose and maybe should not even exist. Or are any known case that the previous behavior would fail?
The patch restores compatibility.
A customer submitted a case where a region contained only a memo. The memo ShiftRelativeTo referenced a subreport above. But the Region ShiftRelativeTo was empty. That's an incorrect configuration, but it produced an ok result.
Via email you stated you have a case where two memos inside a region and memoB ShiftRelativeTo memoA. Looks like that's ok.
Best regards,
Nard Moseley
Digital Metaphors
www.digital-metaphors.com