Can you think of some way to remove a button from a compiled vb6 application - api

We have a VB6 application running at a customer that has a bug in it when the user clicks on the Help button. A quick and easy fix would be to somehow remove the button so that they cannot click it (recompiling isn't an option btw). Possibly a separate app running that is constantly looking for this form and then somehow removing/hiding the button. Can anyone think of a way to do this?

You might be able to find the button window handle using the caption and maybe the class, and then disable it.
This would be pure unadulterated evil, and would sooner or later cause immense pain to you or (worse) an innocent colleague. You really should recompile the application, unless threatened by something worse than a velociraptor.

Related

ShowFileDialog1 Freezing

Okay, I have had the most aggravating problem with OpenFileDialog1. I have a program that I've been using for some 8 months, and in the past month, the program has begun to hang randomly when utilizing the OpenFileDialog1.ShowDialog() function. I have already read through all of the other posts about multi-threaded vs single threaded application. This did not fix it. Enabling the "Show Help" button did not fix it. I am mostly at a loss. here is a thorough walkthrough of the bug:
Run the application. I can always use the Open File button a few times with no problems. It freezes randomly after the program has been running for awhile.
The freeze happens after I push the ShowDialog button, and never displays the Open File Dialog window. The entire program locks up and hangs. If I pause it, Visual Studio doesn't show an error. It underlines the OpenFileDialog1.ShowDialog() in green, which is very odd.
I have found a way to break the freeze. Simply run a second instance of the program and use the OpenFileDialog function. As soon as it loads the file in the second instance, the first instance unfreezes. However, this is not a fix.
The only thing I can think of that may be causing this is the program also uses a WebBrowser1 control. It only seems to happen AFTER the WebBrowser control, which is on a seperate form, not the main form, has been initiated and utilized. Does this make any sense at all?
Thank you for anyone who can help me. I am about to tear my hair out.
Debug your program with dnspy, And when the software freezes, you will be able to see within the dnspy the actual code even if it is in a third party DLL.
I have solved this problem. It was quite unsolveable based on my description above, but hopefully I will help someone with this solution. The error is related to using the IE11 Emulation Control (11000) in the WebBrowser1 control. For some reason this interferes with OpenFileDialog and causes it to hang. I have no idea why. I changed my WebBrowser1 to use IE9 Emulation Control (9999) and the error has gone away. Thank you to those who looked into this. This is a registry entry in HKEY_CURRENT_USER.

Excel ActiveX controls changing size with resolution still not fixed?

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".

Tab Order in Visual Studio hates me

Tab Order in Visual Studio does not work for me for some reason.
I am making a VB.NET plugin for a cad program called Rhinocreos 5.
I have everything set perfect, and I don't know what the cause of it is.
I am using .Show() instead of .ShowDialog(), because I need that thread open and I don't feel like doing any thread management (not paid enough lol)
Does anyone have any pointers for this? Has anyone else ran into a tab problem with Rhino5 and .NET?
EDIT**
Seems I have to use a MODELESS Form for a rhino plugin.... So I wont have any tab keys or arrow keys unless I do a hook. But since I need to make the plugin future proof (in case I am no longer working here), I won't be doing that either. But thanks for the answers, comments, and awesome downvotes.
Very difficult to guess what's going on from the information you have provided, but I'd check the following things in the following order:
The disobedient form is open and has focus.
The form has controls in it.
At least some of the controls are enabled, focusable have their TabStop set to true.
There is no low-level keyboard handling in action (PreviewKeyDown, hooks etc).
Finally I'd call ShowDialog() instead of Show(), passing main form as parameter (to make disobedient form a child of main form) and see if that makes a difference.
It was a modeless form inside of Rhino3D as a plugin.
Rhino3D uses all plugins in the main thread. So tab is not an option.
The workaround was to tag all controls with a tag work (I used "tabMe")
Then I store all the controls in a List myTabbyControls.
Each time I press tab, I would cycle through the list.
But thanks for the down votes. It's the running joke of SO.

How to prevent multiple clicks generating multiple NSOperations

I used Marcus Zarra's excellent advice on how to do async downloads using NSURLConnection and NSOperation. I have tied a button press to that NSOperationg.
Question is: how do I prevent the user from spamming the button and shooting off many NSOperations doing the same download over and over again.
I have two concerns:
a) Setting a global variable is probably not a good idea. What happens if the app is suspended with the flag on?
b) Disabling the button upon the first click is probably a bad idea too. If something goes wrong with my code, the button might stay disabled.
I don't really understand what happens if the app is suspened mid-operation, but mostly I'd like to know the "philosophy" of going about this.
I think most ios apps that consume webservices have this exact same problem, but I don't know what's best practice.
Thank you. I looked and this doesn't seem to be a dupe. If it is, I apologize.
One approach is to show a "loading view" which will cover all of the buttons and give information to the user that something is happening. This has the same problems as disabling the button though: you need to make sure you remove it on completion of the operation, or replace it with an appropriate message if something goes wrong

Code for extending the NETCF MainMenu to support background color property

I've searched for the solution to change the background color on the Compact Framework's MainMenu control, and the only answer I've found is that you need to create a custom control. Does anyone have example code for this?
I did something vaguely similar where I wanted to handle the WM_EXITMENULOOP message which was not available as an event in .NETCF.
The solution was to "subclass" the Main Menu, an old MFC trick where you replace the WndProc function with your own, handle any windows messages (WM_EXITMENULOOP in my case) and call the base class WndProc for everything else.
Some sample code is available on Alex Yakhnin's blog on how to subclass a control:
Example of subclassing a window in .NETCF
In your case you'd actually be subclassing the Form that the MainMenu resides on, and I think WM_DRAWITEM would be the windows message you'd want to handle yourself.
I haven't tried changing the background color myself so not totally sure this will work, but subclassing would be where I'd start.
There is no way of doing this.
Your right in that you'll probably need to create your own control.
This was something I was considering doing anyway to make the application go on Windows CE and Windows Mobile.
The problem with adding menus when the application needs to work with both is that the menu goes to the top of the screen on Windows CE and covers any controls that might be there.
It would be less hassle in the long run just make a new control.
I tried to do something similar a while back and discovered that you have to write your own menu; essentially from scratch. I gave up because the project I was working on couldn't afford the expense. I also discovered that OpenNETCF has a pretty awesome menu control. I don't know if it's included in their free software, but it might be worth looking into.