Hi there,
we created a simple User Control, containing a Panel (size 300, 100) with a few Labels on it to display customer data, and populated a
FlowLayoutPanel with multiple instances (20 -50) of the User Control. Now we have two problems:
We hope you can provide us with some new new ideas on these topics.
Greets
Marcel
Thank you for the feedback. Also you can remove the line with the workaround comment in the sample.
The ShowLoader property is hidden from the designer because it’s not a design-time property. If you set it to true, the control will be blocked by an ajax loader. It’s meant to be used at runtime.
The Scroll event is exposed again in the ScrollableControl class in the current build (not uploaded). It was hidden in the dev build from the base ControlBase class since it’s not relevant at that level.
My problem solved on this topic https://wisej.com/support/question/integration-with-android
Interestingly, when adding touchstart event to flowlayout and other components has flowing content then scrolling becomes smooth.
Thank you.
When I set fillweight to 1, customusercontrols are seen like that. When I adding controls on design time again same thing.
Flow layout doesn’t fluid on mobile.
By the way, when do you publish the mobile controls?
Hi,
Flowlayout on mobile devices are not working expected. I tried and tested again attached sample like as the screen cast and sample also is not working like on the screen cast. I found a something about fillweight on another topic but I couldn’t understand how I can implement.
Thank you.
Hi Luca,
I tried the new dev-build 1.3.24 and the scroll-event worked again. Thanks a lot. But I recognized I couldn’t add the event in Visual Studio Designer (I use VS 2015) anymore, because it is no longer available. I can add the scroll event only in the Code.cs. The same issue occurs for other events and properties of other controls, e.g. the new ShowLoader-property from 1.3.23. It is no problem as long as I know which events and properties a control contains. Maybe I missed something and the problem only occurs on my system, but it seems a little odd because this was no issue with earlier builds.
Best,
Marcel
Sorry, it’s a regression, one more test to add to the regression tests. I can send you a quick patch or you can download a dev build with the fixes by this evening.
Hi Luca,
sorry i have to ask one more time but the solution for “endless scrolling” doesn’t work anymore since I updated to 1.3.23 (it worked fine in 1.3.18). The FlowLayOutPanel got no scroll-event in the newest release, so i can not check if the user already hit the bottom of the FlowLayOutPanel while scrolling. Will the scroll-event return in a later release? Or is there any other way to achieve the same behaviour in 1.3.23?
Best,
Marcel
Hi Luca
and thanks again for the answer. This really helped a lot.
Best,
Marcel
Hi Marcel,
I have attached your sample app modified to use infinite scrolling. You can also easily change it back to use a button at the end of the scrolling. Notice that instead of disposing and recreating the button (now a label) I have simply re-added it to the Controls collection after adding the additional child panels – it will go to the bottom automatically.
HTH
Best,
Luca
Hi Marcel,
Thanks. The fix will be in the next build. It’s not just a change to your test app.
Also, calling Thread.Sleep() ends up slowing down the server, it won’t help on the client rendering side at all. If you call Application.Update(this) while adding panels, the server immediately all the “screen” updates to the client (if you are on a WebSocket connection) and then keeps running. In your case, if you call Application.Update() while adding child panels, the panels show up on the client as they are added (only on WebSocket).
When you create 50 panels with about 20 controls each, at the end of the request Wisej sends back the JSON definition for 1,000 widgets. The client side can create those objects in milliseconds, but then the browser has to render probably 5,000 elements all at once, with many reflows. That’s the freezing that you see, it happens when the browser is rendering dom elements. You can see that with F12 and looking at the screen frames.
There is a compromise between speed and screen update. If you want more “fluidity” while the browser is busy, Wisej can suspend the creation of the dom elements and process the updates only when the browser fires an animation frame (the option is “optimizeFrames” set it in Default.json as “options”: { “optimizeFrames“: true }). However, I don’t think it will help much since in this case, you can see the difference only when the rendering frame is very long.
I’d suggest to create fewer panels at each iteration. You could also handle the Scroll event on the panel and load new child panels automatically, creating the typical infinite scrolling that you see around. I’ll send you a modified sample once the fixes that are required are released.
Best,
Luca
Hello Luca,
yes we used a lot of Application.Update() and Thread.Sleep(), because when we added 50 User Controls or more to the FlowLayOutPanel the whole UI got frozen until everything was loaded. To avoid this we used Application.Update() to simulate dynamic loading.
Anyway, the demo-app you published works exactly as we wished, what are your changes and can you give us the improved code.
Greets,
Marcel
Please try this: http://demo.wisej.com/apps/flowlayouttest
This is what I get now: https://www.screencast.com/t/Pu6peTdWT
Not yet, setting up the samples on a test server that can be reached with a real tablet and not an emulator.
Question: I noticed a lot of Application.Update() and Thread.Sleep() in there. Is it to emulate load or why do you need those?
I also noticed an issue with the scrolling jumping to top when adding the controls and other issues that I will address in your sample and send the code back to you.
Best,
Luca
Hi again,
i just wanted to ask if you could experience the same scrolling behavior on tablet and mobile devices with our test case project and maybe have any further advice for us.
Best,
Marcel
Hello and thanks for the fast answer,
yes we are using the latest build (1.3.16). I send you an example project in VS 2015 (the Wisej.Web and Wisej.Core DLLs are missing because of the max upload size) and the scroll works fine on a desktop. Mobile and tablet stuck while scrolling.
Regarding issue 2 i try to create another example project to show the issue.
Greets
Marcel
Hi Marcel, couple of questions:
Are you using the latest build?
Can you send a test case so that we make sure we are looking at the same thing?
Does the scroll work correctly on a desktop?
Does issue 2 occur on a desktop too and with the latest build?
Best,
Luca