none
flowlayoutpanel limitations / workarounds RRS feed

  • Question

  • I have a flowlayoutpanel tha takes a control which has a few events instantiated when added to the panel.

    My issue is that there is a limit, I add more than 400 controls and I run into an event add limit.

    Is there a way to find out which controls are in view, and only activate events for controls that scroll into view?


    foxjazz
    • Moved by CoolDadTx Saturday, January 14, 2012 5:11 AM Winforms related (From:Visual C# IDE)
    Friday, January 13, 2012 9:05 PM

All replies

  • What is the exact error message?  It sounds like this is perhaps a runtime error message.  Is that correct?
     

    --
    Mike
    Saturday, January 14, 2012 12:32 PM
  • Hi,

    I's add some paging functionality to the FlowLayoutPanel, to display only a visible set of controls, because you also might get some trouble with the amount of WindowHandles when adding a real lot of complex controls.

    Regards,

      Thorsten

    Saturday, January 14, 2012 3:13 PM
  • Please help us clarify your question, could you?

    --> My issue is that there is a limit, I add more than 400 controls and I run into an event add limit.

    What is the limitation?

    I'm using this to ensure which controls are in view:

                foreach (Control ctl in this.flowLayoutPanel1.Controls)
                {
                    
                    if (ctl.Bounds.Y < this.flowLayoutPanel1.Bounds.Height)
                    {
                        Console.WriteLine(ctl.Name + "\t:" + ctl.Bounds.Y+"\t"+ctl.Bounds.Height);
                    }
                }
    

    https://skydrive.live.com/embed?cid=BB789F72272D4858&resid=BB789F72272D4858%21697

    This is my demo.

    If there's any concern, please feel free to let me know.

    Best wishes,


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us
    Monday, January 16, 2012 5:10 AM
    Moderator
  • When I get a chance, I will try Zhang's solution.

    Yes it is a runtime error that I get, and it is solved by limiting the handles.

    After further thought, what I really need to do is take the event handel out of the child control and put it in the parent.

    Which means I need to find the on_click x/y value to see what control it is bound to.

     

    Now my situation is worse. I can't detect mouse click on the control because the controls that are added intercept it or disolve it.

    Very frustrating.

     


    foxjazz

    • Edited by foxjazz2 Monday, January 16, 2012 6:41 PM
    Monday, January 16, 2012 4:58 PM
  • I would like to view your project, so that I can really know what you did in your project, and what logic you probably want.

    Otherwise, it is hard to let me analysis out what you want through your description.


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us
    Tuesday, January 17, 2012 8:54 AM
    Moderator
  • There would be two Exceptions thrown out form the codes.

    But both of them seems caused by the memory corruption, it seems there's no enough continued memory block for allocate to the objects to use.

    It will work if I decrease the collection size number to about 1000.

    And I also cannot recommend you to put so large number of controls to one panel, less control is a good UI design.

    What is the higher-level goal here?


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us
    Thursday, January 19, 2012 5:48 PM
    Moderator
  • The goal is to find a solution to this problem.

    Why is it bad design to add a large number of controls to the panel? The panel I thought was built for convenience.

    There should be a way to handle the onclick event at the panel level itself, not the control level.

    But I don't know how to get that done.

    So I am stuck with limiting the number of records in my control therby limiting the ability of my program's capabilities.

     


    foxjazz
    Thursday, January 19, 2012 7:27 PM
  • I mean it is not a control number limitation, at least it is not proved by the test. It is the size in memory, the continues memory block. You can replace the List<UnitSummaryPanel> to List<Button>, the code will executed without any problem, even we can increase the number of Buttons, it works in my side based on your test project.
    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us
    Friday, January 20, 2012 3:52 AM
    Moderator
  • No it's not memory size, it's the number of handles that c# can take without bombing.

     


    foxjazz
    Saturday, January 21, 2012 4:35 PM
  • I will try to involve another expert into this thread.
    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us
    Monday, January 23, 2012 3:11 AM
    Moderator
  • Hi foxjazz2,

    After consulting another expert, we found that the problem is the Handler number for per process "limitation": http://blogs.msdn.com/b/oldnewthing/archive/2007/07/18/3926581.aspx

    So, I'm afraid that you will need to change your UI design.


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us
    Tuesday, January 24, 2012 9:31 AM
    Moderator
  • Yes, this is what I have been saying all along.

    When you say "change your UI design" I was really hoping for a suggestion for how to change it.

    I would still like to use flowlayout panel, but I can't seem to get the onclick to work when I click on a control in the panel becaue it is intercepted by the control (and therby is nullified).

    So if the flp is not the control to use, what would you do to change your UI design to mimic what I am currently doing?


    foxjazz
    Tuesday, January 24, 2012 2:37 PM
  • Which Button's Click event cannot trigger, can you show me the name?

    I want to help you find it, but I saw there're 4 Buttons appear, but all of them are have not been register the Click event, and the other Buttons are on panel2 which behind the splitContainer1, they have registered the Click event.


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us
    Wednesday, January 25, 2012 11:35 AM
    Moderator
  • Well the issue is that I don't want to create event handles for every button because it becomes too many.

    I want to click on the button, and deptermin which button it is by capturing the event and the mouse position.

    But when I click on a control in the panel, the panel does not capture that mouse click.

    This is currently the only way to resolve the underlying issue.

    This isn't a split container, it's the flowlayout container class.


    foxjazz



    • Edited by foxjazz2 Friday, February 10, 2012 8:15 PM
    Friday, February 10, 2012 8:14 PM
  • Message is passed to on window(control), the container will not capture the click event once you clicked is the control on it.

    button1_Click(object sender, EventArgs e)

    You also can put all the logic codes in one handler method, and jadgement through the "sender" object, you can convert it to Control or Button, then get the Name or the Text property.


    Mike Zhang[MSFT]
    MSDN Community Support | Feedback to us

    Monday, February 13, 2012 5:58 AM
    Moderator
  • Yes that is the behavior that I have seen. This only re-inforces the fact that what I need to be done, can't be done using the FlowLayout Control.

    If I am wrong, then you should be able to take my project, and re-arrange it so that it works with a few thousand controls added to flowlayout.

    Because you aren't adding a click handler on every control, just 1 on the flowlayoutpanel control.


    foxjazz

    Monday, February 13, 2012 3:09 PM
  • Hi,

    We can understand the issue here.  But putting to many controls in form is not quite recommended, and it's even beyond Windows's limitation.  So I think it's very hard to figure out some solutions currently.   As a workaround, we would strongly recommend you reconsider the UI design, maybe we can paging the controls. 

    Have a nice weekend!

    Thanks


    Michael Sun [MSFT]
    MSDN Community Support | Feedback to us

    Friday, February 17, 2012 2:44 AM
  • So you are thinking I should put say 50 in and center page them by deleting or taking them out.

    I would have thought the the flowlayout would have been smart enough to do that on it's own.

    Even so, I would have to separate the data from the controls so I would have to keep a copy and keep track of what the page is at all times. I think it's doable maybe. I will have to take a closer look.

    I will report back after investigating if this is a solution.


    foxjazz

    Thursday, March 1, 2012 6:11 AM
  • Hi,

    Any update?  If you need any further assistance, please feel free to let me know.

    Good day!

    Thanks


    Michael Sun [MSFT]
    MSDN Community Support | Feedback to us

    Monday, March 5, 2012 2:23 AM