I've was playing around with drawing a dynamic grid of rectangles on a form, possibly to eventually turn into something custom-progress-bar-like, and so in testing I've been drawing & deleting them repeatedly.
But I'm confused about the behavior of my DeleteAllRectangles sub. It only wants to delete every second one. I'm probably (rather, very likely) missing something obvious. It's so unimportant as it's only for testing, but it's gonna bug me!
The attached Access 2016 db will open a startup form.
Click 1 to open a second form (intentionally in Design View).
Click 2 to draw a bunch of rectangles.
Click 3 to delete the rectangles. Click 3 again. And again. And again.
Click 4 to see the offending procedure (and likely find my mistake in under 10 seconds!)
Thanks!
(It's a sandbox thus far so it's not very tidy, but pretty self-explanatory.)
it is because controls are kept in a collection and a collection can be visualised as list
So if your list is
10
11
21
22
and you want to delete everything which contains a 1
so
inspect first item of list - 10 it contains a 1, so delete it and the list becomes
11
21
22
with the 'pointer' on what is now the first record 11 - now move next.
So the pointer is now on 21
21 contains a 1, so delete it etc
You can see that 11 never actually gets inspected.
That's the explanation - if you need a solution, google something like 'deleting items from collection' or similar.
PS you can get the same issue when deleting elements from an array - that solution is to start at the ubound and work down to the lbound, but not one that works for collections
with the 'pointer' on what is now the first record 11 - now move next.That's the explanation - if you need a solution, google something like 'deleting items from collection' or similar
Ahh okay, now that I think about it I understand what's going on.
Code:
I'm going:
For each [B]ctl [/B]on form
if current [B]ctl [/B]is blahblah then delete the current [B]ctl[/B]
Next [B]ctl [/B][COLOR=Red]<-- as in, the [B]ctl [/B]I just deleted.[/COLOR] I confused the poor For loop!
I guess the obvious solution is to delete them the same way I created them:
For [B]x[/B] =1 to 10
For [B]y[/B] = 1 to 10
delete control named ("box" & x & y)
Next [B]y[/B]
Next [B]x[/B]
[B]X [/B]&[B] Y[/B] are [I]counters[/I]; they're not getting deleted.
[B]Ctl [/B]is an [I]element[/I]. The same element I'm deleting.
There, I talked myself through it with your help, I can sleep now, thanks!
Mostly I'm just playing and experimenting but I'd sure like to take a look at yours too. I didn't realize how limited Access forms are with drawing shapes. You get rectangles. That's it, that's all. No curves allowed. (Well, I did find a fancy 20,000-line module but that's sketchy in itself since it's tricking Windows into displaying shapes "on top".)
I'm also surprised I couldn't find any decent downloadable controls instead of the lame built-in progress bar -- although there's some pretty cool JS ones that might look okay in a web browser control. I figure I could somehow use a pie-chart control to make a circular progress bar. My plan with the 100's of rectangles is to make them look like blocks "falling into place", if I get that far.
As I said, this is nothing urgent; more of a self-guided lesson, and I'm pushing my (very limited) artistic skill, lol.
without looking at your code, I just want to add that there is a lifetime limit on the amount of controls that can be added to a form if you are indeed adding and deleting them.
Mostly I'm just playing and experimenting but I'd sure like to take a look at yours too. I didn't realize how limited Access forms are with drawing shapes. You get rectangles. That's it, that's all. No curves allowed. (Well, I did find a fancy 20,000-line module but that's sketchy in itself since it's tricking Windows into displaying shapes "on top".)
I'm also surprised I couldn't find any decent downloadable controls instead of the lame built-in progress bar -- although there's some pretty cool JS ones that might look okay in a web browser control. I figure I could somehow use a pie-chart control to make a circular progress bar. My plan with the 100's of rectangles is to make them look like blocks "falling into place", if I get that far.
As I said, this is nothing urgent; more of a self-guided lesson, and I'm pushing my (very limited) artistic skill, lol.
I suppose the thing is that access/databases are really about data management, and not so much presentation - although you can achieve a lot of well-presented forms and reports.
If you outgrow what access can do, then maybe you end up needing a different tool, and build an .exe file with a link to an access back end - you lose the rich built in access features, but you gain in other areas.
This is probably similar to deciding that Word can't do the desktop publishing layout you need, and deciding to use Publisher instead.
I was actually just looking at that post of ChrisO's last night but I guess I got sidetracked by other posts about him before I made it to the attachment. Brilliant! - great suggestions thanks, those will keep me busy for a while!
without looking at your code, I just want to add that there is a lifetime limit on the amount of controls that can be added to a form if you are indeed adding and deleting them.
...but that's just not true! Yesterday I was specifically testing how far I could push it and got a "too many controls" error at around 850 on the form at once, so I set my "max" to 800 and added & deleted thousands after that, same DB, same form. (Running Access 2016, file size & performance is fine, I just compacted every couple thousand.)
[On a side note, during that process I discovered the ControlDefaults option; I wish I would have known about that years ago!]
It's not a big deal in this case since it is just a "sandbox db" and I'll eventually copy what I need over to a fresh one, but I might have to put it to the test later, leave the laptop looping add+removing for a few hours!
As to "custom progress bars" what I did was two rectangles, one on top of the other, called rctTop and rctBottom. Just to be sure, in design mode I used the "Bring To Top" option on rctTop and selected the control by its name rather than using the mouse.
To begin when the form loads, the rectangles are both set to have .Visible = False.
To display them, make the bottom rectangle have visible borders. In my case, it was my preference that the bottom background was transparent, which is the .BackStyle property of 0. The .BorderStyle was 1 (or was it -1? I can never remember.) The .BorderColor in my particular case was a dark green because the form's background was a light green but your color is your choice.
Set the TOP rectangle to have a .BorderStyle and .BackStyle of 1, set the .BorderColor and .BackColor to whatever, and set the .Width to 1. To be pedantic about it, you can also set the rctTop's .Left, .Top, and .Height to match the rctBottom's .Left, .Top, and .Height. That means they will overlap on the display with the TOP rectangle appearing to overwrite the bottom one.
Each time you want to update the progress bar, you just have to recompute the Top's .Width property while leaving the Bottom's .Width alone. You will need to know the minimum and maximum of the item for which progress will be displayed as well as the progress value.
Code:
...
lTwipsPerInch = 1440
...
rctTop.Width = ( ( lProgV - lMinV ) * lTwipsPerInch ) / ( lMaxV - lMinV )
If rctTop.Width < 1 Then rctTop.Width = 1
If rctTop.Width > rctBottom.Width Then rctTop.Width = rctBottom.Width
The parentheses in that width computation are important since you first want to convert the width to Twips, the unit of measure for item placement on an Access display, and THEN compute the fraction. As an option, if your values could possibly exceed the boundaries of the progress bar in either direction, you might wish to have the bar change color to show that it had traversed out of bounds. I usually included a .Repaint in any program step that changed the progress variable's value.
When you are done, just reset both bars to have .Visible = False again.
Doing it this way, you can design the bars for narrow forms, wide forms, and you can even do an axis change by making the bar's .Height be the variable property.
As an exercise, you could build a couple of public subroutines in a general module and pass in the numbers you need for the computations. This is the sort of thing that, once it is in your "tool box," you will use it over and over.
Apologies for the delay - part of my C drive on my main PC got corrupted big time & I couldn't access Windows
I then got stuck in an endless loop after trying to reset Windows
Thankfully fixed after 24 hours or so ...
Finally chkdsk ran & eventually allowed me to wipe the drive & start again...
Anyway, so you can see this in action, I've linked the progress bar to a form timer event just for this example.
Its remarkably similar in action to what Doc Man outlined in his post.
i.e. no fancy shapes - just rectangles.
In normal use you just define the maximum number of steps
e.g. using DCount to count records being updated etc...
Its simple but effective
The code is in a module so it can be reused on any form
I did once try emulating the MS Windows circular progress bar but decided:
a) it wasn't worth the considerable effort
b) the processing load would slow down whatever the background series of events were - which defeats the object really...
Just as a side note, I have a progress bar class saved in the Code Repository. In fact, I have a single bar and a dual-bar setup both saved. Instructions are in the linked post.
Edit: Ridders, I do like the idea of tying the updates to the form timer rather than always to the task's progress. I think I'll be stealing that idea for a future version of mine.
Years ago I found that when processing and deleting attachments in Outlook, I had to use reverse order in order to process all attachments. So, instead of
Just as a side note, I have a progress bar class saved in the Code Repository. In fact, I have a single bar and a dual-bar setup both saved. Instructions are in the linked post.
Edit: Ridders, I do like the idea of tying the updates to the form timer rather than always to the task's progress. I think I'll be stealing that idea for a future version of mine.
I knew there were a couple of progress bars in the repository but had forgotten about yours.
Having just looked at it, its an impressive bit of coding.
However, its significantly more complex than my version.
Whether its faster or not, I've no idea as I haven't compared them
Do have a look at my code if you haven't already done so.
Some years ago, I extended that code to a dual progress bar.
I remember that it wasn't much more complex in my case
If I've still got it, I could post that as well if anyone is interested.
P.S. I've never tied a progress bar to the form timer before either.
I only did it in this case as a way of showing it in use without needing to upload any 'sample' data
