I'm in the process of looking into auto-enabling an IE9 toolbar so the user does not need to click the enable button, and I noticed another company used the following method.
Delete the registry key HKCU\Software\Microsoft\Internet Explorer\ApprovedExtensionsMigration\
Create a new key under HKCU\Software\Microsoft\Internet Explorer\ApprovedExtensionsMigration\
Add my toolbar's CLSID string value HKCU\Software\Microsoft\Internet Explorer\ApprovedExtensionsMigration{XXXXXXX....-XXXX}
x. Internet Explorer 9 automatically enables my toolbar and proceeds as if the user had clicked enable.
I have not found any documentation for this method, but I believe the way this works is Internet Explorer 9 believes the toolbar is going from IE8->IE9, and enables the toolbar. Should this method be considered unsafe for use (too hacky and will instantly get flagged by anti-virus), or is this considered a valid way of auto-enabling a toolbar?
Also, does anyone know if this method works in Internet Explorer 10?
Can't find any resources about this method. Viruses will use this method for sure (see http://www.threatexpert.com/report.aspx?md5=bde1312b225ad987b57b1dbef0885817 which is an identified virus that do exactly that), but since this registry is deleted (or at least the Time Stamp value is changed) in legitimate scenarios, it is possible that anti-viruses will not freak out, as they don't want to create false positives.
Regardless, what you are trying to do feels bad.
Also you should consider other users on the machine (not currently logged in).
Related
I have a question about an ActiveX Control I am developing. I have hashed my way through most problems but I am stuck at a real road block. This ActiveX is being imorted into other software so I have to have a good implementation of the Property Pages. I have managed to get some persistant properties working with one issue. When I make a change in the property page it is updated and persists as long as the application that is development app that is using it is open but it reverts back when I reload the app. I have narrowed this down to the fact that the development app doesnt realize the ActiveX has changed and therfore doesnt save. If i make a unrelated change and save the program all is good and the values persist as expected. I have tried everything and cant seem t get the application that imports my ActiveX to realize when it has changed via the property page. I am wondering if anyone has some work arounds for this type of problem. It seems to me if I could force the DoPropExchange() it would work but I dont know how to call this explicitly.
Thanks in advance
Matt
Thanks for the input. I did have the SetModifiedFlag() but it wasnt working. After poking at it I solved that problem but now I am redirecting my question. I had removed the property above in question from the idl files dispinterface in order to prevent the application that loads the activex from displaying the property in its "Connection List"(3rd party application specific"). It appears that the app loads all the interface into this list but this is not good as some properties should be persistant and only modifiable through the proppages. I tried all the flags like hidden and local but still were displayed in the list. When I removed it from the dispinterface it was how I wanted it but would not signal the IsModified. My new question is in there another way to define properties for an instance like this or is it possible to have a secondary interface(I have not tested if the application would see this interface because I am not sure how I would go about defining this inteface)or to have a property only between the proppage and control. Or is there another way to signal the dirty. The OnMemberVariable of the control was properly executing I know from testing it just seems SetModifiedFlag() doesnt do anything if the property is not in the dispinterface
Thanks Again
You need to mark your control as "modified", so that its host could detect it and re-save persistent properties. In this case IPersistXxx::IsDirty implemented by your control would indicate dirty state.
MFC based control has COleControl::SetModifiedFlag for this purpose:
Call this function whenever a change occurs that would affect your control's persistent state. For example, if the value of a persistent property changes, call this function with bModified TRUE.
Update: To hide a property from property browser you can use nonbrowsable attribute.
Use the [nonbrowsable] attribute to tag an interface or dispinterface member that should not be displayed in a properties browser.
I have an application on C++ (on Windows API) and I ask the user to approve a task using MessageBox. However, as it's a bit sensible task and nobody reads the message, I want to change it to have an input box and the user type "I agree".
Does anybody know a simple way to do that? I find DialogBoxParam() which can do it, but it's overkilling for my needs, can you think on something more simple (or a simple way to use it)?
I found Prompting a user with an input box? [C++] quite similar to my question, but there is no satisfactory answer for me (using another lib is not an option).
You would have to write your own dialog for that. The MessageBox and related APIs do not offer such functionality. You could use the task dialog API (introduced in Vista) to show a dialog box with a button having customised caption. That might be a little better than plain MessageBox with its limited set of buttons.
I'm a little cynical about what you are trying to achieve in any case. If you force the users to type I agree they will ignore the content of the dialog box and type what you ask them to type.
The difference in outcome between your typing dialog and a standard button press dialog is that the user will take longer to get past the dialog, and will dislike your software, but the still not have read the content of the dialog. In other words, the only thing you will achieve by doing this is to hold up the user.
At some point you have to accept that the user takes responsibility for their actions. If you give them a helpful message and they choose to ignore it, ultimately that is on them.
As the context menu for the desktop and explorer windows is disabled, I wanted to make a little something to bring back some functionality. My idea was to just list out things in a context menu (copy, paste, new, open with, etc) whenever a user right-clicks one of these windows, and then just simulate the appropriate event in the actual menu (file->new, edit->copy, etc). It wouldn't look perfectly pretty, but it would hopefully allow for the use of right-clicking.
The problem is that I cannot seem to get the actual menu. I opened My Documents and tried going down the child list towards SysListView32, calling GetMenuItemCount each time. Most returned -1, and the only other return value than that was 0.
How am I supposed to get a handle to the (file, edit, view...) menu?
If this isn't possible, is there a way I could simulate the user clicking something on the normal context menu, even if it's disabled?
Also, is there a way of making this work for the desktop? You can get the same type of thing if you view it in the explorer window, so I figured there might be a way.
I'm running Windows XP and any help is appreciated.
As per David Heffernan's comment,
As for your question, you are on the wrong track.
GetMenuItemCount needs an HMENU but you've been feeding it HWND.
That won't work. It also won't work from a different process.
You could possibly write a program that use the shell COM APIs
to show a context menu for a shell item. But your basic problem
is the bone-headed group policy. You really need to get that fixed.
Tell the IT guy that takes the decision that I said he was a fool
and was stopping you doing any useful work. ;-)
This led me onto the path of using the correct alternative method to achieve my goal.
I'm working on a credential provider for windows 7 with cpp. I want to disable textboxes and submit button while the system is working in the background. For this I tried to use the code below:
_pCredProvCredentialEvents->SetFieldInteractiveState(this,SFI_EDIT_TEXT,CPFIS_DISABLED);
At here SFI_EDIT_TEXT represents the object that I want to change it's properties and CPFIS_DISABLED shows it's should be disabled (at least i assume that is). But I didn't get any useful result. Anyone can able to help?
There are a several situations, where using SetFieldInteractiveState won't work. For example, if user have pressed "Submit" button, your's provider GetSerialization function will be called, and no GUI changes will be done by LogonUI until you return from GetSerialization. I think changes of GUI are made only between calls of your provider's functions.
P.S. I know, that question was asked long time ago, but in future, maybe, my answer can help others.
Asking because in the previous question i was pointer to IExplorerBrowser, however it creates a child window, while Explorer's "Find Target..."behaviour i want to simulate (see previous) exhibits some level of control over newly open or existing Explorer window (i believe that right term is folder view, feel free to correct). Also looking for other API(s) to accomplish BrowsingTo or similar behaviour.
This isn't possible. See Raymond Chen's blog post on the subject.
Aha, the program is using Explorer as a “view this folder for a little while” subroutine. Unfortunately, Explorer doesn’t work that way. For example, the user might decide to use the Address Bar and go visit some other folders completely unrelated to your program, and your program would just be sitting there waiting for the user to close that window; meanwhile, the user doesn’t realize that your program is waiting for it.