I have a form with a lot of controls (1400 controls), when I click off the form it locks up my computer. Eventually my computer will resume processes but obviously this is not the outcome I want. Any insight as to why this is happening?
Printable View
I have a form with a lot of controls (1400 controls), when I click off the form it locks up my computer. Eventually my computer will resume processes but obviously this is not the outcome I want. Any insight as to why this is happening?
really 1400 controls ?
what are you displaying
Im looping through a databases of around 30 records, with about 50 fields that populate all different kinds of controls. I am then adding them to a panel. I wanted to build this in a web form, but the users have specifically requested it be added to a current desktop app I built them. They want to be able to view all records in the database at once with the correlating controls :(
I should have asked this in your other thread... but it wasn't obvious at the time what you were doing... so I'm going to ask it now... why not use a grid? That's what it's for.
-tg
Yeah I agree. Even if the DGV doesn't have the control you want, you can us additional controls outside the grid. This seems to be a job for a Bindingsource. Even without a dgv you only need 50 controls and a bindingsource.
As far as your question goes, it's hard to give an answer without seeing any code.
With 1400 controls, how would you even find the one you wanted to use?
Maybe a screen capture of what your form looks like might be helpful. We might then be able to suggest some ideas.
Im posting an example of the UI, it may better explain what the end users are expecting. You can see two records displayed in the image, obviously if they scrolled down the panel there would be the rest of the records. I haven't added all the controls yet, I'm hesitant to seeing how its already freezing my computer. Basically they would be able to go down the list of records, make changes with the controls and then hit and update all button.
Attachment 178190
OK, so you have 2 records on that screen. Can your form be resized so that you can see more than 2 records at a time without scrolling? At the maximum form size, how many records could actually be visible at the same time?
The idea is that you show only the maximum number of controls on the form needed for the records visible simultaneously. Then, when you use the scroll controls, you don't show new controls, but change the record data shown on the already visible controls.
I thought about that as an option, but when brought up to the end users they said they would rather be able to scroll back and forth between individual records. Unfortunately, your suggestion is not what they want... much to my dismay.Quote:
Originally Posted by jdc2000
The users would not see any difference, other than that the controls would not scroll, only the data would.
I am aware, and I agree, but this is the way they want it unfortunately. On describing end users: something about leading a horse to water...Quote:
Originally Posted by jdc2000
Well, it's a very bad design. When they see it in action they'll be disappointed, have a plan B ready.
Meanwhile, as I said before, can't help without seeing your code.
Why are you allowing the end user to dictate the nuances of how the code functions? If both options present the same UI and experience, and one option is ridiculous (loading hundreds of controls, the vast majority of which will always be hidden from view) and causes massive application lag, and the other option is logical and performs well, why are you allowing the end user to dictate option 1?Quote:
Originally Posted by Christhemist
An apt analogy based on your avatar is allowing Homer Simpson to design a car.
Let the end users suggest workflow and UI experience, but it should be up to you how to actually implement things in code.
It's how the current design is (inside access) but they want it replicated inside the desktop app i build them...Quote:
Originally Posted by wes4dbt
Having build business systems for the last ... 20+ years... I've come to the following conclusion:
What users ask for is not what they need.
What a user thinks they want is not what they need.
What users think they do is not what they need.
True story: I was at a client helping to gather requirements. We kept getting "we want what the current system does" ... and they gave us the user's manual.... bleh... we were replacing one our products with another... to make the new one work/look like the old was going to be a bad design and a bad choice for the users... they would be frustrated. And I told them so. I threw the manual back on to the table and gave them a speech about "green fielding" the requirements - in other words, this was the time to make things better... after all, if they wanted everything to work and act like the old system, then why the hell were we there? Keeping on that, the things they were asking for - was it because its' what they were used to? Was it driving their business? Or was their business driing the requirements? I don't think anyone had ever talked to them like that before. It changed the nature of the discussions.... and they began to see that what they were asking for (make new system like old system) was not the right thing to do.
Users do NOT know what they want until they have it in front of them, then they know that that isn't what they want - even if it is what they asked for. And it's up to people like us to challenge that.
My guess is that they are asking for that because that's what they've always had and it's what they're used to and don't know any different. IT woldn't surprise me that if you put something just as functional in front of them, but different, they may actually be responsive in a positive way to it.
-tg
I guess I would consider at least limiting the number of controls.
Perhaps create four panels, each with the same set of controls.
You position the four panels vertically inside your scrolling panel.
You are displaying the top two panels.
As they scroll through the records, you get to the point where the two middle panels are displayed, if they continue scrolling and the fourth one is beginning to come into view, reposition the first panel to the end of the stack, and load it with the fifth record data.
Each time you have 1.x panels off the top, you reposition the top one to the bottom and load the appropriate record.
If they start scrolling the other way, when you have 1.x panels off the bottom, move the bottom panel to the top, load the appropriate data into it.
lolQuote:
Having build business systems for the last ... 20+ years... I've come to the following conclusion:
What users ask for is not what they need.
What a user thinks they want is not what they need.
What users think they do is not what they need.
Learning to get a true product definition was a lot harder than the programming. There is always the, Well I assumed it would..., I thought you knew ..., oh, we can't do it that way because.... , sometimes we have to do it differently....
what does inside access meanQuote:
Originally Posted by Christhemist
is this a Access Desktop App
try using a Treeview to load Data (with multiple Nodes/Levels)
this could be a compromise --> they can see all the Data to select from
you can then use the TreeView1_AfterSelect to load
that specific Data
like wes4dbt said
Quote:
have a plan B ready.
The best is when you try to ask then what the steps are that they do... inevitably there's steps that they forget because they do it so naturally they don't realize that they are doing it.Quote:
Originally Posted by wes4dbt
User: I do X, Y, Z.
Me: When I do X, Y, Z it doesn't come out right.
U: Oh, yeah, that's because I find I need to do A & B between X & Y so that Z will accept it properly....
Me: Bangs head on desk.
That's why things like the waterfall method tend to fail and there's a push for something like agile... get it into the hands of the users faster.
-tg
I did few tests and benchmarked reading from database and creating many controls.
First is the reading from MSSQL. When data is read for first time it takes between 50 and 400ms. Next reads are quick - 1-5ms, because of the connection pool, data cached in memory (using always same records), etc. Test was performed with 30 and then with 100 rows.
Now about generation of controls using big FlowLayoutPanel and adding inside single row FlowLayout panels. Each row flow panel is filled with 20 text boxes and populated from the db record info.
30 rows * 20 text boxes took about 450ms each time. Increasing the number of rows to read and display to 100 makes the things really annoying as each creation of controls takes about 1500ms on average. This second and a half is far away from the comfortable 200-300ms for page view*
* Page view time is separate discussion about web sites and how users react to slow sites, but it can be applied here too - 200-300ms could be assumed as comfortable time
So optimized database access (when we have already established connection in the pool) is not the problem. In my code first I've added async database reading but after benchmarking I changed it to non-async code to see how it will affect the experience. These 1-5ms should not be considered as part of the problem.
Since the problem is in the UI, I've tested how fast it will be using user control. The control contains all required controls - labels for each field and text boxes or date time pickers for the data. The results were worst - 2000-2100ms.
The question I have now is how Access can show such data faster? Maybe it is the way the controls are defined? Well, since I already have user control that can show the info, why not to add 30 or 100 of these manually to the FlowLayoutPanel or add dynamically during form load?
Now the dynamically added user controls take about 1200-1300ms for 100 user controls (now using constant to fine tune the testing). But then showing data by calling my routine in the user control is very fast - results from first run (no SQL connection established already) and second run:
Now the question is how to optimize adding these controls during form load event. I haven't tried adding manually 100 user controls during design time. And I am lazy to do this test :)Code:------------------------
add controls: 1160
------------------------
get data: 127
show data: 17
------------------------
get data: 2
show data: 2
Now about the discussion what customers/users want and what in reality it should be. I have similar experience like techgnome. Usually everything starts with very complex requirements where UI changes are horrible, affects multiple products of the stack, and finally it becomes small tool that is started once per week and shows only progress bar and errors log (if any).
It is hard to convince someone that solution provider provides the solution and no arguments like "but we want it like the old one or like this" are out of scope for the new (and different) product. Same applies for technologies used: "we want web and mobile app" when the "app" is used in single office by one or two users, there is no need of servers or services exposed to internet, and the data is required once per month as report that is simple Excel file + PDF printout which can be send via e-mail to few managers.
Sometimes some developers (and software dev companies) are trying to provide to customers/users very complex solutions for small problems and this affects future thinking and expectations of these users. Make it simple, do it sequential as workflow in the UI and make it fast. That is what should be made and expected by both sides. But now is the trend to setup multi-servers (like tens or hundreds) with hundreds of microservices, complicated control layer for containers, setting overbloated NoSQL databases which are still version 0.6.xx and supported for internal use by some "big player" company by hundreds of devs, devops and other kind of ops (like "ooooops - it crashed Saturday evening" :D). I forgot to mention that for 500MB data (created in 20-25 years) now is required very expensive server setup with terabytes of RAM and storage...
I've decided to present them with one set of controls for them to page through all records, however they are going to want an autosave every time a change is made. Am I beating myself over the head with how many database writes this is going to end up with?
Not necessarily... just only save when there's a change... if there's no change, don't save...
You might want to read up on BindingSources.... In short they work like this:
* you get your data in a datatable/set
* create a BindingSource and attach it to the datatable
* bind your controls to the BindingSource you created
* Now you can navigate through the BindingSource and the bound fields will update controls
* When the user navigayes to a new record, you can first check to see if there was a change to the current record, and if so, save it
-tg
Awesome, thanks for the help and insight everyone.Quote:
Originally Posted by techgnome
Show your approach and present the advantages - workflow with simplified data view and navigation. No one will read and modify 200+ fields, so it is better to keep single record info on single "page". If users need some info from previous/next page, then show only that info, e.g. previous and next item numbers and descriptions near by the buttons to move to prev/next record.Quote:
Originally Posted by Christhemist
For the db saves techgnome wrote you how to do it.
For a speedy way for the user to navigate to a certain record, also add a DataGridView to the form and use the same bindingsource for it's datasource. Then the user can just scroll through the dgv and select the desired record and it will be displayed in the individual controls. Just a thought. Good luck
How would I go about checking if there was a change to the current record? Do I want to save every time a control's value has changed, or is there a more streamlined way of doing this?Quote:
Originally Posted by techgnome
Quote:
Originally Posted by Christhemist
-tgQuote:
Originally Posted by techgnome
....
NoQuote:
Do I want to save every time a control's value has changed, or is there a more streamlined way of doing this?
How often you save changes depends on who you ask. Some say not till all edit/add/deletes are done. When they exit the form. I'm not brave enough for that, afraid something could happen and a lot of work could be lost. I usually save the data each time the user moves to a different record or exits.