We are using "#opentok/client": "^2.15.10"
We are trying to give additional visual feedback when the browser asks for microphone and camera permissions.
We based our solution on the Publisher event 'accessDialogOpened'.
This works very well in the case where the permission dialog is actually open and the user needs to act on it.
For some reason this event triggers in cases where the user has previously given permissions which causes some ux issues for us. (the dialog never actually opens in this scenario)
Eventually a subsequent event 'accessDialogClosed' follows after roughly 500ms which remedies the problem but still we have an undesired flicker.
My question "Is this expected and I should find a way around it? Is this a bug which can be fixed in a followup releases?"
I tried to reproduce the exact issue and it's working fine for me now, there was some slight mistake for which there is this workaround.
Wrong-> accessDialogClosed, function (event) { // The Allow/Deny dialog box is closed. } });
Correction--> accessDialogClosed: function (event) { // The Allow/Deny dialog box is closed. } });
Hope it helps!
Related
When I press the back button on the window, then it is not getting closed. If I remove the back button handle, then it is getting closed. Below is the code snippet.
$.myWindow.addEventListener("android:back", function() {
// perform some action
});
Can someone please let me know as to why it is not closing?
You need to close the window manually if you handle the back button. For example the code should be:
$.myWindow.addEventListener("android:back", function() {
// perform some action
$.myWindow.close();
});
This should resolve the issue.
Above answer is incomplete in few terms.
1. android:back event has been deprecated since Ti SDK 3.0.0.GA
Use new event androidback till Ti SDK 5.5.1.GA. This is exactly same but it will not be removed in future versions & android:back will be removed.
2. androidback also has been changed since Ti SDK 6.0.0.GA.
From 6.0.0.GA, using androidback simply closes the window automatically & executes further code. Simply means, it doesn't over-ride the behaviour of back button press. To over-ride back button behaviour, you must use Ti.UI.Window onBack property
Stick to latest behaviours & changes & you won't need to change your code after future updates.
I have another wxWidgets question regarding events and focus.
I have already looked at the tutorials and this old question here but I am still running into problems C++ Event (Focus) Handling
Basically I have a dialog with two wxTextCtrl elements and a Button.
What I would like to achieve is, that when I click on button it needs to tell me which of the two elements previously had the focus.
In the constructor of my Dialog I created all the elements and then connected them to the eventhandler like this: Ttop->Connect(TOP,wxEVT_KILL_FOCUS,(wxObjectEventFunction)&UI_ADDENTRY::hasfocus);
Tbottom->Connect(BOTTOM,wxEVT_KILL_FOCUS,(wxObjectEventFunction)&UI_ADDENTRY::hasfocus);
then there is the eventhandler that safes the id into focus
void UI_ADDENTRY::hasfocus(wxFocusEvent& event){
focus= event.GetId();
event.Skip();}
however when i try to access focus in the Button function it always tells me: 0 instead of TOP or BOTTOM / the ids that I gave the textcontrols
void UI_ADDENTRY::OnRecord(wxCommandEvent &event){
wxString tmp;
tmp << this->focus;
wxMessageBox(tmp);}
What am I doing wrong? is there another way of finding out which of the two textbox has been in focus last?
Thank you
The most fool proof way is to catch EVT_SET_FOCUS in your text controls and remember the last one that received it. This is not more difficult than what you are doing but should work without problems.
FWIW EVT_KILL_FOCUS can't, unfortunately, be consistently implemented on all platforms, in particular GTK+ doesn't give any information about the window focus is being lost to.
In think u mean event.GetWindow().GetId(). Though I'm not sure how ur casting from int to string.
i'm still having a problem clicking a popup button on an auction site,that appears only if u won an auction. This popup seems tbe a problem. Ive managed to get help partially in Need to click a bid button with Grease monkey script, i'm able to get the bid buttons clicked, but the popu is stil a problem. The xpath for the popup is:
.//*[#id='ctl00_mainContentPlaceholder_Button3']
And the script i'm using currently is:
// ==UserScript==
// #name click popup try1.3
// #include http://www.trada.net/*
// ==/UserScript==
// ctl00_mainContentPlaceholder_Button3
function PopClick ()
{var PopBtn1=document.getElementById("ctl00_mainContentPlaceholder_Button3");
alert('try1');
PopBtn1.click (1);
alert('finished');
};
PopClick();
But the problem seems to be that the script doesnt stay active on the page waiting for the popup, I think if i can get it to "wait" for the popup to appear, it should work. I'm very new to GM, so excuse if there is simple errors. I had exelent help from people like Brock sofar, who is showing me the ropes. Slowly but surely I'm gettin the hang of it. Remove the alerts, i just used them to see if it executing.
The simplest solution would be to run this function, say every second, thus "waiting" for the popup to appear:
setInterval(PopClick, 1000);
It is also better to rewrite PopClick to check if the element is there, before calling click, like this:
function PopClick () {
var PopBtn1=document.getElementById("ctl00_mainContentPlaceholder_Button3");
if(PopBtn1) {
PopBtn1.click ();
// It is also makes sense to clear interval here. see docs for setInterval/clearInterval please :)
}
};
May be this will help you with the freezing issue.
The more proper way, however, would be to set up MutationEvent listener. Since you are using Firefox, it should work OK:
function click_if_popup(evt) {
if(evt.target.hasAttribute('id') && evt.target.getAttrubute('id') =="ctl00_mainContentPlaceholder_Button3")
evt.target.click();
}
document.addEventListener('DOMNodeInsertedIntoDocument', click_if_popup);
Sorry, I didn't test any of this code: I wanted just to give you the general idea of where to dig.
I have a bit of a challenge.
In an earlier version of our product, we had an error message window (last resort, unhandled exception) that showed the exception message, type, stack trace + various bits and pieces of information.
This window was printscreen-friendly, in that if the user simply did a printscreen-capture, and emailed us the screenshot, we had almost everything we needed to start diagnosing the problem.
However, the form was deemed too technical and "scary" for normal users, so it was toned down to a more friendly one, still showing the error message, but not the stack trace and some of the more gory details that I'd still like to get. In addition, the form was added the capabilities of emailing us a text file containing everything we had before + lots of other technical details as well, basically everything we need.
However, users still use PrintScreen to capture the contents of the form and email that back to us, which means I now have a less than optimal amount of information to go on.
So I was wondering. Would it be possible for me to pre-render a bitmap the same size as my form, with everything I need on it, detect that PrintScreen was hit and quickly swap out the form contents with my bitmap before capture, and then back again afterwards?
And before you say "just educate the users", yes, that's not going to work. These are not out users, they're users at our customers place, so we really cannot tell them to wisen up all that much.
Or, barring this, is there a way for me to detect PrintScreen, tell Windows to ignore it, and instead react to it, by dumping the aformentioned prerendered bitmap onto the clipboard ready for placing into an email?
The code is C# 3.0 in .NET 3.5, if it matters, but pointers for something to look at/for is good enough.
Our error-reporting window has these capabilities:
Show a screenshot that was taken when the error occured (contains all the open windows of the program at the time, before the error dialog was shown)
Show a text file containing every gory detail we can think of (but no sensitive stuff)
Save the above two files to disk, for latter attaching to an email or whatnot by the user
Sending the above two files to us by email, either by opening a new support case, or entering an existing support case number to add more information to it
Ignore the problem and hope it goes away (return to app)
Exit the application (last resort)
We still get screenshots from some users. Not all, mind you, so my question is basically how I can make the PrintScreen button help us a bit more for those users that still use it.
One option: Put the stack trace and other scary stuff into the error screen using small, low-contrast type -- e.g. dark gray on light gray -- so that the user doesn't really even see it, but the Print Screen captures it.
But if you want to detect the PrintScreen and do your own thing, this looks like an example of what you want.
Wouldn't it be possible to disable the Print Screen button altogether when the error popup is active? Have it display a message along the lines of "Please use the clearly visible button in the middle of your screen to report the error" I agree it breaks expected functionality, but if your users are really that stupid, what can you do...
Alternatively, have it report errors automatically (or store the data locally, to be fetched later, if you can't send without asking for some reason), without asking the user. If you want to be able to connect print screened screenshots with detailed error data, have it send a unique ID with the data that's also displayed in the corner of the popup.
What about offering them a "Print Screen" button that performs these actions as well as performing the print screen? If you're locked into this method of having your customers send error details, this may be an easier route to take.
Lifted from my comment below for easier reference (looks helpful, perhaps):
codeproject.com/KB/cs/PrintScreen.aspx
This is in theory...the best way to deal with it I would think
Intercept a WM_PRINT message or inject one into your process... see this article here
Install a system-wide keyboard hook and intercept the print-screen key and swap it around with your contents prior to the capture. Now, I can point you to several places for this, here on CodeProject, and here also, keyboard spy, and finally, global Mouse and keyboard hook on CodeProject.
Now, once you intercept the print screen, invoke the WM_PRINT message by capturing the contents that you want to capture.
I know this is brief and short, but I hope this should get you going.
The only solution i came up with was to offer big, large, easy to read toolbar buttons that give the user every opportunity to save the contents of the error dialog:
Save
Copy to clipboard
Send using e-mail
Print
And after all that, i use the Windows function SetWindowDisplayAffinity in order to show the user a black box where the form should be:
This function and GetWindowDisplayAffinity are designed to support the window content protection feature that is new to Windows 7. This feature enables applications to protect their own onscreen window content from being captured or copied through a specific set of public operating system features and APIs. However, it works only when the Desktop Window Manager(DWM) is composing the desktop.
It is important to note that unlike a security feature or an implementation of Digital Rights Management (DRM), there is no guarantee that using SetWindowDisplayAffinity and GetWindowDisplayAffinity, and other necessary functions such as DwmIsCompositionEnabled, will strictly protect windowed content, for example where someone takes a photograph of the screen.
If their screenshots show a big black box, hopefully they'll get the hint.
I did add a defeat, if they hold down shift while clicking "show error details", i don't add the protection during form construction:
//Code released into public domain. No attribution required.
if (!IsShiftKeyPressed())
SetWindowDisplayAffinity(this.Handle, WDA_MONITOR); //Please don't screenshot the form, please e-mail me the contents!
It's a longshot that anyone can help with this, but here goes. I inherited a VB6 app with a Janus GridEX control. It iterates through records, and is editable. Problem is, if I edit a cell and hit the button to go to the next record, the change is applied to the next record, not the one I was editing. It's like, I need it to finish up the edit before going to the next record. I've had this sort of problem before in VC++, and sometimes you have to "KillFocus" on the control you're on or something. I just don't know what to do here. I tried sending a carriage return, since if you return out of the edit cell, it works, but sending a carriage return manually doesn't work. What's the secret?
Is your grid bound or unbound?
It's hard to tell from your description, but I imagine that if your are having this problem then it's probably bound.
As the other answer asked, is the button the RecordNavigator that is built into the control or is it a separate button? The reason I bring this up again, is that I have seen issues in the VB6 applications I support where a toolbar will often intercept and interfere with how the JanusGrid should work.
To get around this limitation, I have added the following code in the click handler of any toolbars where there is also a JanusGrid control on the form.
If jsgxYourGridName.EditMode = jgexEditModeOn Then jsgxYourGridName.Update
This way any changes are immediately applied to the current row.
If this does not help, then I have also seen problems where the recordset that is bound to the grid gets out of sync with the internal recordset in the grid. You can check this by comparing the bookmark of the grid to the bookmark of the recordset.
Ie. mrsYourRecordset.Bookmark = jsgxYourGrid.ADORecordset.Bookmark
At one point I may have also used something like this.
jsgxYourGrid.ADORecordset.Bookmark = jsgxYourGrid.RowBookmark(jsgxYourGrid.RowIndex(jsgxYourGrid.Row))
Finally you can try setting a breakpoint in the BeforeUpdate, RowColChange and/or AfterColUpdate events of the grid, to see what record the grid is really on when clicking on the button.
It depends whether the button is internal to Janus GridEX or not. If it internal then just about the only thing you can do is look at the events the control exposes to see if there a sequence that can let you know that this problem occurs. Then you can try to take corrective action by restoring the row you moved to and put the edit in the row you left.
If the button is external to Janus then you can use the debug mode to trace sequence of statement that control the transfer of focus to the next row. It could be something out of order or a side effect of the particular sequence of commands. I have run into both with different controls.
Remember that you can edit while in debug mode so you can try different approaches and test until you find one that works.