This is a question with the same title as here:
VBA Active-X buttons getting bigger with every action
I guess the problem is the same.
The question is nevertheless from 2014!!! and it does not really have an answer.
In my case the buttons were NOT created programatically, but just clicking in insert activeX control, button, and then click for writing the VBA behind.
In order to better illustrate the problem I made a video with my handy:
https://www.youtube.com/watch?v=hBiu2FfRxQU
IN the video you can see how every time a button is clicked it gets bigger.
as note aside I have to say that this only happens when I connect remotely with my computer via a think client. Nevertheless both screens are the same (i.e. have the same resolution).
This is of course very annoying because it makes almost impossible to use home working since connecting to my excel at work makes all the buttons go crazy in size.
As #TimStack and #jvdv has pointed out this is a known issue of Microsoft, i.e. a BUG, there since many years.
Hence there is no solution but workarounds.
So stay away from controlX if you don't want to get surprises.
I had faced this issue today itself. And found very strange solution to this problem.
I just tried to resize the button where I was facing the issue and it was solved.
Hope this works with you.
When I open Logisim on my Windows 10 device, the task bar options are all clumped together and difficult to read(Screenshot tagged in the post). But looks fine on mac.
Screenshot of Left side Task Bar
Any help would be great.
Try pressing Windows Key + Up key.
Another possible solution is to hit the Windows button. This tends to bring up the task bar in most programs, for me, at least.
This may seem off topic, but I'd create a manifest file for this particular program if it occurs only there. That may solve the problem if done correctly.
I feel the need to understand why, while I'm working in eclipse, some keys stop working, especially backspace and del keys.
I have searched on the net and found that it is recognized as a bug: I often read that the problem is related to other applications.
So the best advice is to restart Eckipse. (???)
Someone should explain to the Eclipse's developers that it cannot stop working (or working bad) if some other application stops working or crashes.
ps. Now I'm working in Ubuntu, but I see that the problem is platform-independent.
If you use many keyboard layouts, you may have accidentally changed them by pressing alt+shift. If that's the case, pressing it again will restore it to the normal layout.
I've had this issue several times and usually I can just shut down the program and restart it. But this time I have a bunch of windows open and I don't want to restart Dreamweaver.
My problem is that Dreamweaver brought up a code hint, but the code hint box now won't go away. It just sits there floating in the middle of the page. It doesn't matter if I click to Preview or any other tab in Dreamweaver, it still just sits on top of everything.
I'm working on a Mac, Dreamweaver CC (cloud, fully updated). Anyone else have this problem???
This has been a HUGE PAIN for me as well! You can make the code hint disappear though by finishing out an element that is in the code hint box. For instance if the code hint box appears and you can see class in the drop down... create a <div class="xyz"> real quick and the code hit box will dissipate after you close the quotes on the class because you used an element in that box. As to why this continually happens on the Mac version I have no idea, but I hope they fix it soon!
It's a known bug since years as you can read here: https://forums.adobe.com/message/7745689
Someone suggests as a workaround to set the Coding Hint delay to 0 (as said here: https://forums.adobe.com/message/7745689#7745689) but for me, in Dreamweaver CC 2015 Windows fully updated via cloud app, this bug still occurs while I code JS files.
Awaiting for a final fix, I hope this suggestion can be useful for you on Mac. :)
We've got some in-house applications built in MFC, with OpenGL drawing routines. They all use the same code to draw on the screen and either print the screen or save it to a JPEG file. Everything's been working fine in Windows XP, and I need to find a way to make them work on Vista.
In three of our applications, everything works. In the remaining one, I can get the window border, title bar, menus, and task bar, but the interior never shows up. As I said, these applications use the exact same code to write to the screen and capture the window image, and the only difference I see that looks like it might be relevant is that the problem application uses the MFC multiple document interface, while the ones that work use the single document interface.
Either the answer isn't on the net, or I'm worse at Googling than I thought. I asked on the MSDN forums, and the only practical suggestion I got was to use GDI+ rather than GDI, and that did nothing different. I have tried different things with every part of the code that captures and prints or save, given a pointer to the window, so apparently it's a matter of the window itself. I haven't rebuilt the offending application using SDI yet, and I really don't have any other ideas.
Has anybody seen anything like this?
What I've got is four applications. They use a lot of common code, and share the actual .h and .cpp files, so I know the drawing and screen capture code is identical.
There is a WindowtoDIB() routine that takes a *pWnd, and a source rectangle and destination size. It looks like very slightly adapted Microsoft code, and I've found other functions in this file on the Microsoft website. Of my four applications, three handle this just fine, but one doesn't. The most obvious difference is that the problem one is MDI.
It looks to me like the *pWnd is the problem. I'm not a MFC guru by a long shot, and it seems to me that the problem may be that we've got one window setup in the SDIs, and more than one in the MDI. I may be passing the wrong *pWnd to the function.
In the meantime, it has started working properly on the 64-bit Vista test machine, although it still doesn't work on the 32-bit Vista machine. I have no idea why. I haven't changed anything since the last tests, and I didn't think anybody else had. (On the 32-bit version, the Print Screen key works as expected, but it does not save the screen as a JPEG.)
Your question title mentions screen capture but your actual question doesn't. Please elaborate more clearly. Is the problem that you can do screen capture of three of your applications, but not the fourth one? You can use different screen capture software that can capture OpenGL/DirectX windows. Those surfaces are handled directly by the Window Manager and won't show up with a simple 'PrtScn'.
Switching to GDI+ won't solve it, nor will switching to SDI.
If it's the content of the CView that you want, then yes, that should be right one. If it's the content of the whole screen (at least the content, without the toolbar(s) and status bar), then you should pass it the CMainFrame (that's the default name which may have been changed, the one that is derived from CMDIFrameWnd).
Can you post the code of WindowToDIB()? I've just tried it and It Works For Me (TM), but without OpenGL code in the view. Try passing the following windows to your WindowToDIB() function:
CMainFrame* mainfrm = static_cast<CMainFrame*>(::AfxGetMainWnd());
- mainfrm
- mainfrm->MDIGetActive()
- mainfrm->MDIGetActive()->GetActiveView()
and see what you get.
The contents of each window are directX surfaces and are only assembled by the window manager in the graphics card. You'd not be able to capture this unless you switch off the new interface (DWM) or code specifically for screen capture from the DWM.
Wikipedia has a good description of the Desktop Window Manager (DWM)
Sorry, I still don't understand. You're trying to get the Print Screen key to work on all four applications? Or you're trying to get the WindowtoDIB() function to work, which takes a 'screenshot' (from within your own application) of the application itself, so that it can be saved as an image file?
Also, what do you mean with 'he Print Screen key works as expected, but it does not save the screen as a JPEG.'? Print Screen only copies to the clipboard, what happens when you paste in Paint?
If your WindowtoDIB() function only 'captures' the window you pass to it, then yes, your MDI child windows are not going to show up.
We eventually solved this by creating a different OpenGL context, and drawing everything to that. We gave up on the screen capture.