I've been working on a dashboard for the past several months in Excel 2010 and was nearing completion when we were upgraded to Excel 2013. I have experienced one issue that I'm completely stumped on...
I built a simple UI for the dashboard utilizing the first several rows of each sheet. Essentially, each sub-menu is hidden in a different row and only the appropriate rows are visible at any time. Is also allows the user to toggle on/off the various menus in/out of view without using a userform.
Prior to upgrading to 2013, it was very snappy and responsive, taking around 0.05 seconds each time a change was made in the UI. However, after migrating to Excel 2013 the UI is very sluggish. At first I thought it was a screenupdating issue because the screen was updating in bits and pieces - the labels, hidden rows, background color, etc would come in chunks, instead of all at once. I've ruled that out as a possibility.
I also tried disabling all of the annoying new animations that are baked into 2013. I tried all of the different methods I saw out there online - disabling the hardware graphics acceleration, turning off unnecessary animations in the ease of access center, etc. That too seems to have no effect.
After a full day of troubleshooting, I've noticed a sheet with just the UI and nothing else runs just as snappy as before. It's only when there are objects on the worksheet that things go wrong. From what I can tell, shapes and text boxes seem to have no effect on performance. Labels, both form control and Active X, seem to be the culprit.
I've noticed that the little bits of code I have for the UI continue to run at the same speed, but the screen will continue to change even after the procedure has run. This also totally perplexes me. I have tried changing the property from Move and Size with Cell to Free Floating and neither seems to make any difference. I've also tried changing things like Print Object, Locked, etc.
I'm totally stumped as to how to resolve this issue. It's definitely something endemic to 2013 as the exact same file runs without issue on 2010. If anyone has any suggestions they would be greatly appreciated.
UPDATE: Here is a link to a sample file highlighting the issue. Both work fine when tested on 2010.
https://www.dropbox.com/s/r2ep5bgyn6ohjph/2013%20Issue.xlsm?dl=0
Granted this is a stretch, but a little bit of research tells me that Excel 2013 has suffered a number of problems with ActiveX controls. There were several patches Microsoft has released, so I recommend you install them first and make sure your copy of Excel 2013 is completely up to date.
https://support.microsoft.com/en-us/kb/3025036
https://support.microsoft.com/en-us/kb/2956145
If this does not fix the problem, please let me know and I will remove this answer.
All, thanks for your help. I finally solved the issue I was having. I isolated the problem to Form Controls or ActiveX controls being visible at the time the code is run. I'm not sure why but the presence of either creates an issue. However, hiding all shapes prior to running the code and then unhiding them after resolves the issue. I did notice, however, this solution only works if the code does NOT turn screenupdating off prior to execution. I will post an updated file later when I have access to dropbox.
Related
I have written an app that makes extensive use of custom right-click menus on an Access form. The code works great and the user loves it, but lately I am having trouble making it work properly.
In earlier versions of Access it worked well, but newer version seem much more limited in how many items can be put in such menus. The documentation is silent on the matter, and nobody in any newsgroup has had any useful ideas, but I regularly get random error about stack space, out of memory, and general lockups when populating the menus. Doing a C&R used to help, but now even that is not enough, and some menus I can no longer populate at all.
I tried building an app that just built menus until it crashed, to get some idea of what the limits may be, and I am well below what that indicated, but the experimental app had nothing else, while the real app has a great deal else.
Is there any information on how much stuff can be put into these menus, and what the menus share space with? There may be something I can do another way to make more room for the menus. I tried moving all code out of the form, leaving only event stubs that called routines in standard code modules, but that did not help.
And how are they stored/activated? The app is MUCH slower to load when it has these menus, even though no code is running on start-up.
********** Edited to add this:
I use VBA to create a menu, like this:
Application.CommandBars.Add "RCStat", msoBarPopup, False, False
then add it to a control. like this:
Application.CommandBars.cboStat.ShortcutMenuBar = "RCStat"
I add controls (only popups and buttons) like this:
Application.CommandBars.Controls.Add(type:=msoControlPopup)
Application.CommandBars.Controls.Add(type:=msoControlButton, Parameter:="StatKod = 77")
It runs perfectly and the menu items work exactly as expected, except that it bombs after adding some number of controls. It doesn't seem to matter where I add them, just the total number of added controls hits some undefined threshold, and the app crashes.
I got the original code from Getz, Litwin and Gilbert, 2000 edition. Back then, it worked great. But as the versions advance and the app accumulates data, it is becoming less and less functional. However, there are only around 10,000 records, and the app itself is less than 100MB - nowhere close to any of Access's upper size limits.
Pete,
I've done quite a bit of work with shortcut menus, and created the Access Shortcut Tool about 5 years ago, but have never attempted a menu with so many controls although some have 3 or 4 levels.
I am not aware of any restrictions on the number of elements in the commandbars collection, but I find that shortcut menus with too many options, like lists and combo boxes with too many items, are difficult for users to navigate. I generally break these up into segments and use buttons in the form header to display the appropriate menu. Sorry I'm unable to provide anything more helpful.
Dale
We have a commercial product, Total Access Components, that includes as one of its 30 components a right click popup menu that can include icons and font styles.
Here's the info for the popup menu control: https://fmsinc.com/MicrosoftAccess/controls/components/popup-menu/
There's a free trial if you want to try it.
I have a document into which I copy all kinds of VBA code regarding questions asked on this site and write code in preparation for answers. This document was created on my PC (with Word 2010). It has no event procedure that runs on the Save event, but at some point a few weeks back it started to ask me the above question before every save, including automatic saves. The document is based on the Normal template which has no code in it. I don't know which code may have caused this to start, nor which code to even suspect. Other documents open in the same instance of Word save normally. It's only this one document that is affected.
The document also contains a lot of special items, like content controls, fields, ActiveX controls, EndNotes, tables and comments. I suspect the comments to be related to this problem in some way.
I know that I could probably stop the alerts by disabling alerts but that isn't what I want. I want Word to display all the normal alerts. It's just this abnormal one which I would like to switch off. Any ideas how to do that? Or what caused Word to issue that alert in the first place?
In these situations I make several backups of the document and then start looking for something that is broken. So using a new backup each time, I systematically delete portions of the document to see if the unwanted / unexpected behavior disappears. For example I first try to isolate the issue to the top of bottom 1/2 of the document. If I can establish that the issue is related to the bottom half then I delete half of the bottom half of the document and so on... it can take a while but it has been an effective method of finding issues for me.
That said, I tried this on a document recently and just ended up going round in circles. I thought I had narrowed the issue down to a single corrupt image, but that turned out to be NOT the case.
I've also found that there are some things that I can do with VBA that Word simply can NOT undo... I'm only aware of a few things (which I'd have to look up in my notes) but I'm sure there's a whole list of things.
A possible workaround might be to clear the undo history for this specific document prior to saving, I imagine that will suppress the message and save you from losing the standard notifications. Hope it helps :)
Good luck!
OK, this might be a bit of a generic and repeated non-code question but the latest article I can find about this is from over 2 years ago, so I'm wondering if there's been a fix or an update or maybe some clever dude out there has cracked the secret to curing this.
Every time I extend my screen while Excel (2007, 2010 or 2013) is running, and every time I unplug from an extension while Excel is running, my ActiveX controls are rendered useless, because with each click they either shrink or get bigger, depending on if I extended or unplugged.
This happens until I close the Excel application and restart it, unfortunately if I've saved it while the buttons are bigger/smaller they might end up stuck like that.
There is a thread here which has a bit code to help deal with the issue but quite frankly I'm hoping by now, two years later, someone has a slightly more efficient method of dealing with it.
I've took to using hyperlinks to run macros now but that's no good for my drop-boxes and things. And for me personally, I can just make sure I close Excel before extending/unplugging, but the real issue is I'm developing apps for people around the company and it's starting to cause problems with these damned buttons.
Does anyone know of a definitive fix for this yet?
If you only need ActiveX buttons to run macros, use Shapes instead. You can assign macros to a s shape's Click event. Right-click the shape and select "Assign Macro".
When working w/ a WinForm project in VS.NET 2015, our team has noticed that the mere act of opening a .VB form in the designer view (default action when double-clicking the file in Solution Explorer) will cause VS to modify many object properties in the "Windows Form Designer generated code" section of the actual .VB code-behind. It seems to be limited to the .Size and .Location properties for sometimes dozens or more of UI objects, always changing their X,Y coords just slightly.
Mind you we don't perform any action to drive this -- simply open the file (obtained from source-control and residing in the local solution/project) in VS.NET's form designer by double-clicking the file in Solution Explorer, and bam -- it has the "unsaved" asterisk and if you save it and compare to source control version you can see the modifications already made.
I couldn't find much on this. Is this a known behavior? Any idea why it does this? Kind of reminds me of the old days w/ MS FrontPage's designer view, and even the early days of ASP.NET in VS which would apply some HTML changes if you opened a WebForm in designer view, until they gave the option to disable that on a later release.
thanks for any input.
UPDATE: this appears to be continuing even with myself as the only editor of the .VB form in designer. various form elements are shifting their position very slightly. Here's a diff screenshot between my last check in and today, and I know I'm the only one editing:
...there are many like that. Always these two properties, always just a few pixels difference.
I don't have an specific answer for this, but since this drove us crazy a bit a few months ago with my team, while working on a WinForms project, I am glad to share my experience!
Every time someone opened any form on VS2015, it would ask other people who has the same solution open at that time to reload the code. We first thought the third party controls (at that time it was both DevExpress and Infragistics) we are using were re-generated on designed initialization - because they tend to do that a lot but then we realised this kept happening on forms that only contains .NET controls.
Now the funny part. This only happened to us on VS2015. We were using VS2013 before, without this annoying problem.
Long story short, then we realized the screens we are using have different DPIs, just like Cody Gray said. I am not absolutely sure if this was the reason, but since we started using TFS, obviously we don't have the problem anymore... Hope this helps somehow lol.
I was working at the forms designer and yesterday the designer literally only showed the form. Tried copying the .designer.vb to another new form and the same thing happened. Also when built it just shows what the designer shows. Compare the two versions:
(Had to use pastebin as the code is too long for a post, and it rejects my post if more than two links are used.)
Current code: pastebin.com/SsgR7YWD
Current form view:
Previous code: pastebin.com/bXCL3jhH
Previous screenshot:
Why it is not showing the controls? I know it is a long piece of designer code but I can't find where the error comes from.
I've just run your code through this site that compares to blocks of text and shows the differences - there's a lot - you might want to do the same and have a look at the differences. It may be easier to delete the form and start again to be honest. Having said that, you might be able to spot what went wrong
You should just delete the form and start again. A few tips to having a better UI ---
Use layout grids for the button-checkboxes and let the buttons occupy the whole horizontal space.
And remember to backup your code often so that things like this won't happen again - use something like GitHub and commit your files whenever your day is finished.
Happy coding!