I've been working on upgrading an application, and I've come upon two brick walls, although this question will only pertain to the first.
We allow users to add attachments from a web-based document service, so when the user clicks a button on one of the forms in our application, it opens up an instance of Forms.WebBrowser, which is essentially an IE wrapper. I've added a Value to the registry to make it run in IE8 compatibility mode, as this document service doesn't support IE7 compatibility mode (of which Forms.WebBrowser defaults to). This is the only change that I've made to the Forms.WebBrowser instance that I create.
When I open the WebBrowser, it instantly gives me a popup saying to install a plugin for the document service, of which I know for sure is already installed on my computer. I can click install or do not install, and it still appears to works fine. The problem is, this happens every single time I open the WebBrowser from the application, and I really don't want my users to come across this and become confused by what they have to press every time that they want to add an attachment from this document service.
Is there any way to make the WebBrowser reference the already installed plugins for my normal install of IE, or if this isn't possible, is there a way to automatically accept or decline the plugin installation (app is running in full-trust), or even a worst case scenario, can we make the Forms.WebBrowser block all popups, and just continue without the plugin?
Try using the ScriptErrorsSuppressed Property. It should disable all dialog boxes, not just script errors.
Related
I have got a vb.net windows service that runs a File System Watcher to monitor an xml file for changes, when it detects a change it will stop the screen saver running and what I would then like it to do is give one of the other running applications the focus.
I have successfully used Appactivate from a Windows Form App in the past but I think I am correct in saying this doesn't work with Windowless applications (I have tried it and it doesn't).
I have done some Googling but I can't seem to find any way of getting the focus when called from a service \ windowless app. Is this possible?
Thanks
what if you make it a single instance application? and then simply launch its .exe file? it might give focus to the other running application instead of opening a new instance.
Our web-based ERP application prevents a user from opening a second browser window with the same URL, via a bunch of JavaScript that checks window names etc.
The point is, you can only open one instance of the application and if you attempt to open another, you get a warning message and the application refuses to open.
When I use
cy.visit('our application')
the Cypress main window gets updated with our application's URL
the Cypress browser window gets updated with our application's URL
This immediately flags our application as trying to open a second copy which then prevents it from opening in the Cypress-controlled browser, which prevents any further testing!
Is there any way to prevent this happening. I have tried using various flavours of baseUrl in the cypress.json file, but nothing has been successful.
Anyone have any useful ideas?
At a client of mine, in-house applications are all located on a network share. Users create shortcuts to the required applications from the network share so we can easily make sure everyone uses the latest version.
This works fairly well, although we often have an issue when users are still using applications when we'd like to release a new version. For most applications, we'd forcibly remove all the file locks on the server and release the new version. Not a very elegant solution, especially since we need assistance from another department for this.
For newer applications, I've developed a cleaner solution, where the application intermittently checks if it's still the most recent release. If it isn't, it shows a message to the user, asking him to quit the application at first convenience, or within 3 minutes. After 3 minutes, the application quits itself and all is well. However, some users will immediately try to re-start the application. The application will then show a simple MessageBox telling the user this version is currently not supported. My problem is this: while this MessageBox is visible, my executable is still locked.
I'm looking for any of the following solutions:
Releasing all locks on the current assembly files from within code
Showing a message box that lingers after the current assembly has exited
This is exactly precisely the problem that .NET ClickOnce deployment is meant to solve. Users have a shortcut they can click, the latest version is downloaded on application start, and there are no server-side executables to be locked if a user leaves their process open.
ClickOnce Deployment Overview
HowTo:Publish a ClickOnce Application
I am attempting to write a small, lightweight client, using vb.net winforms, that can install without needing elevated privileges. Before I ask my questions, let me give you a bit of an idea of what it is supposed to do.
The app will start when Windows loads, set like this from the install, with a system/notification tray icon that can be clicked on to load up specific functionality. The application install from a website, or possibly a file share, haven't quite decided yet. This client will initially request user credentials for one of our web programs, and it will talk to an already built web service to determine what functionalities of our services they have licensed access to. After this, credentials will be encrypted and saved to the users pc locally. Every five minutes, the client will pass the credentials to the websites they have access to and check to see the status of jobs that are being processed, and download available reports if needed.
So, here is what I am trying to understand. If I configure this app as a ClickOnce application, once it installs from the url or shared drive, the user will not need to do anything else, correct? Or do they have to visit that url every time they boot up to reinstall/run the client?
Another thing, I wanted to get some opinions on the best ways to do some of the things this app will be doing. I have a good idea of where I am going with it, but I have no idea of which solution to go with yet.
For instance, what is the best way to store user passed credentials on their system for a "remember me"?
Also, is the best way to have the client install with automatically starting on windows startup to configure it to create a shortcut of itself in the windows startup folder?
I am trying to keep this as lightweight as possible, and using a very small GUI, so it shouldn't be too intrusive, so any ideas on how to ensure that, while keeping it from needing admin privs to install, will also help.
If I configure this app as a ClickOnce application, once it installs
from the url or shared drive, the user will not need to do anything
else, correct? Or do they have to visit that url every time they boot
up to reinstall/run the client?
Well if they need to reinstall it, they would have to download the setup.exe file again, but why would users need to do that? CilckOnce supports automatic updates. Visiting url is certainly not needed for running the program.
what is the best way to store user passed credentials on their system
for a "remember me"?
Probably storing them as application settings. Haven't used visual studio 2012, but in visual studio 2010 you have to right-click on project in solutions explorer, go to project propeties and then create variables in Settings tab. Then you can access those variables in code using My.Settings.variableName. Not sure about security though, if you need any.
As for privileges, I think you just need a privilege to install a program. Maybe you should publish a primitive clickOnce application and experiment with it and that will answer all your other questions about clickOnce.
I have created an application that exposes a OSX service for certain file by adding an NSService entry into my applications info.plist (as in http://www.macosxautomation.com/services/learn/), but I find that upon installing my application on a new machine the service doesn't show up quickly in the finder right click context menu.
I know that this is because pasteboard services hasn't re-indexed the /Applications folder and "discovered" the newly installed service.
I also know that I can force a re-index and discovery by manually running /System/Library/CoreServices/pbs.
The question here is what is the best way to ensure that my service shows up as quickly as possible for users who are installing my application for the first time.
I could execute a system call to "/System/Library/CoreServices/pbs" when my application starts up --If the user immediately starts my application--, but that only partly solves the problem (in addition I wonder if there is a better Cocoa API based way of doing this).
If my application is generally only accessed via the context menu, a user will never think to go out and start the application in the first place. They will only think it is broken when the context menu isn't there.
I am not distributing my application with an installer. I am simply providing a bundle that can be dragged and dropped into /Applications (as I believe Apple usually suggests).
Is there a way to expedite the process of service discovery when doing an installation in this fashion, so that there isn't any period of time where the user is without the newly installed service?
As a side note, it appears that the problem may not exist in 10.8 (or at least be as pronounced). Apple may have made this indexing happen more quickly in their most recent release.
I've actually ended up using
system("killall pbs;/System/Library/CoreServices/pbs -flush");
in one of my apps, just as you describe, though it's a long time ago, when 10.5 was in question as well.
You might want to try this function, however:
void NSUpdateDynamicServices(void)
which according to the documentation acts just like flushing pbs, but is a cleaner solution.
Also, if (according to your description), the app is nothing but a service, consider making it a really just a service - see (Installing the Service)
To build a standalone service, use the extension .service and store it in Library/Services.