Strange behavior of controls in a frame control since 1275

Posted by: thorsten on 4 August 2017, 2:37 pm EST

  • Posted 4 August 2017, 2:37 pm EST

    Hi,

    first thanks for the bugfix CR#15337. Now I am able to build a list wizard.
    But since I have installed build 1275, label controls and other controls in a pane of a frame control have a stange behavior. The text of the labels will print at the wrong position. So in some cases the text will print only at the left side of the label. In other cases it will print outside of the label and when you are moving the label, the text will not move. In the AR viewer everthing looks fine.
    And if you want to put a control to the frame, it will be put on the section, if the frame is not selected before
    In the attachment you will find some pictures which descripes my problem.

    Best regards,
    Thorsten Blawatt


    2005/05/Pics.zip
  • Replied 4 August 2017, 2:37 pm EST

    If you can provide me with a small sample with detailed instructions on how to reproduce your issue with incorrect positioning of controls, I can submit a new CR for it.  With the same information for the label text printing outside the bounds of the control, I can submit a CR for that as well.  I was not able to reproduce either of these issues on my machine.

    As for needing to highlight the frame control before placing controls inside it, this is a usability issue that exists in previous builds (in at least 1253) due to customers requesting a change in useability.  As I mentioned in the following thread, we are not going to change the usability of the frame control at this point in the product's lifecycle:
    http://www.datadynamics.com/ShowPost.aspx?PostID=74649

  • Replied 4 August 2017, 2:37 pm EST

    Dear DD,

    can you please give me a short statement to this thread.

    Best regards,
    Thorsten Blawatt
  • Replied 4 August 2017, 2:37 pm EST

    For text overflowing controls inside the frame control I have created CR 16763.  You will be notified via email when this issue is resolved.

    If you want vertical lines that don't interfere with the CanGrow ability of controls, you can also set the AnchorBottom runtime property of the line to true.

    I did re-examine the highlighting of the frame issue and found that this issues exists in all public builds after 1225.  I have created CR 16765 for this issue.
  • Replied 4 August 2017, 2:37 pm EST

    Hi Peter,

    in the attachment you will find a sample which describes my problem. When you move the controls in the frame you can see the behaviour.

    " As for needing to highlight the frame control before placing controls inside it, this is a usability issue that exists in previous builds (in at least 1253) due to customers requesting a change in useability"

    Sorry, but I don't really understand this sentence. What should be the final behaviour: having to select a frame and then adding a control to it or having ActiveReports automatically select the frame upon the first click when placing the new control? (Until build 1253 you could add controls to a non-highlighted frame.) Most of your customers desire the latter behaviour. The first behaviour is very inconvenient when you want to add 10+ controls to a frame control because you repeatedly have to highlight the frame control before you can put a control on it. So there's always one more step to add a control to a frame.

    In the Thread "Frame controls problems in the designer" you wrote that most designs could be created without frames. But if you are using datafields which CanGrow and you are using lines to group some datafields, it is necessary to use frames, because the borders of the frame are growing with the datafields. Otherwise you would have to script it. But this is not reasonable for our customers.

    If the designer behaviour has really changed in this respect, we would very much prefer a property to control its behaviour.

    Best regards,
    Thorsten Blawatt

    2005/06/AR Frame Sample.zip
  • Replied 4 August 2017, 2:37 pm EST

    Hi Peter,

    you assign the AnchorBottom property at runtime of the report. We want to assign it at the runtime designer. As I see you doesn't save the value of the AnchorBottom property in the rpx file. Is there a reason for? Or is it a bug?
    Our customer build their own reports and we need to give them some comfortable report designer tools. We are in need of the frame control as an host for other control collections. We are adding this collections programmatically. So we have build a listwizard which allows to create a completly list report in a few steps. In a vb form the customer can specify the column count, width and layout. After, the controls will create in a frame (with a specific Tag) with one pane. For the column separator we are using lines. Now we are able to catch resize events and so on.


    Best regards,
    Thorsten Blawatt
  • Replied 4 August 2017, 2:37 pm EST

    Is there a reason why it is a runtime property? So when a customer build their own report this property cannot be used.
    But this isn't really important for me.

    Best regards,
    Thorsten Blawatt
  • Replied 4 August 2017, 2:37 pm EST

    AnchorBottom is a runtime property only.  It is not available at design time, and therefore not written to the RPX file.  You can include it in the RPX file if you add this code in script.  Another option is to set this property on the report object to the applicable lines before calling the Run method (when changing to preview mode).
  • Replied 4 August 2017, 2:37 pm EST

    Hi,

    The AnchorBotton property doesn't work with vertical lines, only with horizontal lines.

    Best reagards,
    Thorsten Blawatt
  • Replied 4 August 2017, 2:37 pm EST

    Hello to all,

    -as you propably know I am an avid supporter of the Frame Control.
    -with 4 years worth of hindsight working with the Frame Control I sincerely believe that most if not all of it's usability problems could be addressed by a programmer if only one was given full programmatic access to the Panes collection; thus providing the ability to implement an custom user-friendly interface for manipulating indivudual Pane Dimensions, addition/removal of controls, Border issues etc.
    -It only takes a relatively small amount of work from DD's side to expose a few properties and methods of Panes in a Hotfix. Nothing fancy, just bare-bones access to the Frame/Pane object model. That would pave the way for creating truely awesome functionality.
    -One could have implemented a beautifull (programmatically) enhanced end-user designer if one's hands weren't tied by aforementioned lack of exposure.

    -I can still dream and hope.

    Regards,
    ArthurDent

  • Replied 4 August 2017, 2:37 pm EST

    AnchorBottom works on any line.  See the attached sample. 

    2005/06/AnchorBottom.zip
  • Replied 4 August 2017, 2:37 pm EST

    I have added your email address to the notification list for CR 14830 to make AnchorBottom a design-time and public property.
Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels