Vista puts out a new security preventing Session 0 from accessing hardware like the video card, and the user no longer logs into session 0. I know this means that I cannot show the user a GUI, however, does that also mean I can't show one at all? The way my code is set up right now, it would be more work to make it command line only, however if I can use my existing code and just programmatically manage the GUI it would take a lot less code.
Is this possible?
The article from MSDN says this:
• A service attempts to create a user interface (UI), such as a dialog box, in Session 0. Because the user is not running in Session 0, he or she never sees the UI and therefore cannot provide the input that the service is looking for. The service appears to stop functioning because it is waiting for a user response that does not occur.
Which makes me think it is possible to have an automated UI, but someone told me that you couldn't use SendKeys with a service because it was disabled in Session 0.
EDIT: I don't actually need to show the user the GUI
You can show one; it just doesn't show up.
There is a little notification in the taskbar about there being a GUI window and a way to switch to it.
Anyway, there actually is a TerminalServices API command to switch active session that you could call if you really needed it to show up.
You can write a separate process which provides the UI for your service process. The communication between your UI and service process can be done in various ways (search the web for "inter process communication" or "IPC").
Your service can have a GUI. It's simply that no human will ever see it. As the MSDN quote suggests, a service can display a dialog box. The call to MessageBox won't fail; it just won't ever return — there won't be anyone to press its buttons.
I'm not sure what you mean by wanting to "manage the GUI." Do you actually mean pretending to send input to the controls, as with SendInput? I see no reason that it wouldn't be possible; you'd be injecting input into your own program's queue, after all, and SendInput's Vista-specific warnings don't say anything about that. But I think you'd be making things much more complicated than they need to be. Revisit the idea to alter your program to have no UI at all. (That's not the same as having a console program. Consoles are UI.)
Instead of simulating the mouse messages necessary to click a button, for instance, eliminate the middle-man and simply call directly the function that the button-click event would have called.
Related
I'm having a problem where when I click on submit in a dialog box the resolve event on the dialog box is supposed to call a function. The dialog closes when the button is click but the api function is never called (as seen from dev tools). If I stop the tests and manually do the action in the cypress browser it will work call the function. I'm not sure why the manual click is acting different than the test runners click?
Sometimes you need a hard ms wait(should be avoided)...
You may have a wait issue. Add a cy.wait(1000) 1000ms hard wait and see if that fixes it. If it does, you will want to identify what hasn't loaded fully when the button is pressed. While hard waits should be strongly avoided, I find myself using them sparingly with the smallest amount of milliseconds(x2 for safety) that I can get by with. Animations are one such example that comes to mind.
Make sure all subscriptions are ready
I am working on a meteor app that using websockets(tricker to wait on than xhr events). I call a method that returns true/false for all subscriptions. This helps wait for any events that cypress doesn't see in the network layer. Ask your devs if there is a method in your application that returns true/false depending on the ready state of the application.
Review for Race condition
This could be a legitimate race condition. I would review it with the devs just in case.
I'm using the Firefox permissions API documented HERE
I'm having a problem with the request method, wherein all of my permissions requests result in:
Error: permissions.request may only be called from a user input handler
You can produce this in firefox by debugging any addon or extension and entering browser.permissions.request({origins: ["https://google.com/*"]}) into the console.
I find it hard to swallow that a permissions request must always have a user input event callback in the parent stack trace. I'm using Vue.js, and my Permissions are due to user interaction, but my user interactions are decoupled from the events they trigger.
What counts as a user input handler?
Why does it work like this?
Is there a good work-around?
Is there a good work-around"
I'd like to add onto Andrew's answer with some code examples.
As it turns out, promise chains destroy the browser's notion of what is and isn't triggered by a user input handler. Take the code below, for example:
document.getElementById('foo').addEventListener('click', event => {
browser.permissions.request({origins: ["https://google.com/*"]})
})
This code works as expected. I originally assumed that it was Vue.js's unique event handling framework that was eating my "browser events", such as when you do <div #click="somefunc"></div>. This actually works just fine, as long as you put your permissions request in somefunc.
Now it gets fun. If you replace your permissions request with a promise that resolves and then does a permissions request, VIOLA!
Promise.resolve('foobar').then(foobar => {
browser.permissions.request({origins: ["https://google.com/*"]})
})
Results in:
Error: permissions.request may only be called from a user input handler
Why does this happen?
I'm going to guess it has to do with stack traces. Firefox can't detect that a permission came from a stack with a user input event at the root if the permissions request happens in a promise chain.
I consider this to be a pretty egregious design choice. My app is large (>4K LoC) and to keep it simple I rely on promise chains to keep the spaghetti away. This has crippled my ability to write clean code, and as a result, I've moved from asking for optional_permissions and then prompting the user for permissions only when needed to just being overly permissive at the time of installation.
GG, Firefox.
What counts as a user input handler?
A DOM event handler that corresponds to user input (e.g., target.addEventHandler("click", ...) or a WebExtension event listener that corresponds to user input (e.g., browser.browserAction.onClicked.addListener(...)
Why does it work like this?
Partly for basic UX (if a user is not directly interacting with an extension and a prompt for the extension suddenly prompts up, it can easily confuse them), but also to avoid clickjacking attacks where the prompt is put up at a carefully chosen moment when the user is likely to be expecting some unrelated prompt.
Is there a good work-around?
I think just organizing your code so that you request permissions from a user input handler is probably your best bet.
I'm writing a Cocoa app, and I need to indicate to the user that a view is invalid and can't respond until a background job is completed.
Longer version:
A view in my app contains some data fetched from a server. When the app determines that the data is invalid, it fetches fresh information and displays it. Usually the update happens too quickly to see, but if server or network problems cause the background job to take more than a second or two, I need to make sure the user
Cannot interact with the view until the job is finished;
Can tell that the view is awaiting an update; and
Can continue to interact with other parts of the application until the job is finished.
1) is important because any operation initiated with the stale data will fail, and if the network or the server is slow, I don't want the user to waste his time with futile attempts to interact with that part of the application. (It's fine if the user can still see the data. That could conceivably be helpful, actually, but it isn't crucial.)
What is the standard way to do this in Cocoa? For what it's worth, in the Eclipse framework I think I used the showBusy method on ViewPart.
If there isn't a standard way, does anyone have any suggestions for tackling it? I haven't been using OS X very long, so I'm not even sure how an app is supposed to look and behave in this situtaion. (The screenshots on this page looking promising, but it's iOS, not OS X: http://cocoawithlove.com/2009/04/showing-message-over-iphone-keyboard.html)
Right now I'm working on replacing the whole view with an NSProgressIndicator and restoring the view after the task finishes, but removing the view means my app could end up in a funky state if something goes wrong. Also, I'd like to be able to factor this functionality out into its own class or category(?) since I will have this issue with several different view classes in my application. Ideally I'd like to end up with something as simple as Eclipse's view.showBusy(true)/view.showBusy(false).
Any and all help would be appreciated.
Thanks!
Why not just draw another view on top of the busy view? You could either have it display an image that means busy, or draw it as semitransparent, so it shades out the before-update version of the busy view.
Is it possible to stop the back button from working during a data call? For instance, when registering, I don't want someone to press the back button otherwise they may register for my service and not know it (other than confirmation email)? (And the registration will fail the next time they try)
Handle the BackKeyPress event or override the OnBackKeyPress method in your page class, and then set e.Handled = true; when you want to prevent backwards navigation.
Note that if you do this, then you should provide the user with a way to cancel your long-running process so they can back out if they want to.
Please note that if you stop the Back button from working your application will fail marketplace submission.
See section 5.2.4 Use of Back Button.
If a user has the situation where they try to reregister (becuase they don't realise they have registered previously) then you should handle this in your app as the situation may come up anyway.
I'm now writing a Bonjour service listener class, according to the document here:
Currently, it seems working, I can receive "netServiceBrowserWillSearch:" and "didFindService:moreComing:" correctly. However, after a long wait, I cannot receive " netServiceBrowserDidStopSearch:" or "netServiceBrowser:didNotSearch:". Therefore I don't know that is the proper time for my delegate class to stop showing some UI.
Could anyone have an idea for this? Thanks.
NSNetServiceBrowser doesn't stop browsing (and call the -netServiceBrowserDidStopSearch: delegate method) until you explicitly tell it to by calling -stop. After it's found the initial services, it continues informing you as new matching services are added or old ones disappear.
How you handle this depends on how you want your app to behave. If you have a window that continuously shows the available services (e.g. like the Bonjour window in iChat), then it's best to let it continue, and contiuously update the list in response to delegate messages. If you've got more like a dialog that gets populated and then goes away once the user makes a selection (e.g like the system Add Printer... dialog), then you want to keep the browser running while it's displayed, then call -stop once the user dismisses it. If you're waiting to find just one specific service, then you can call -stop once you've found and resolved it.