I'm working in Chrome for MacOS (108.0.5359.124) and Microsoft Edge (107.0.1418.62) on MacOS 12.6.1 (though confirmed the same issue on 13.0.1 as well), and the reset() method of WebUSB does not seem to work - I get no error on the console, but the device also doesn't see the reset.
Meanwhile, the same code does generate a USB reset in Chrome on Linux (same version, 108.0.5359.124, under Ubuntu 18.04 with kernel 5.4.0).
The code is here:
const connectButton = document.getElementById("connect");
const resetButton = document.getElementById("reset");
let device;
connectButton.onclick = async () => {
device = await navigator.usb.requestDevice({
filters: []
});
await device.open();
console.log("open:", device);
await device.selectConfiguration(1);
console.log("select config 1:", device);
await device.claimInterface(0);
console.log("claim interface 0:", device);
};
resetButton.onclick = async () => {
console.log("Device before reset: ", device);
await device.reset();
console.log("Device after reset:", device);
}
I see all the console logging, and no errors are thrown. (If I try to claim one of the HID interfaces on this device, I do get errors - but I believe that's expected). I've also tried without the device.selectConfiguration() and device.claimInterface() calls - exactly the same behavior (ie, no errors, but it doesn't work).
Is there something under MacOS preventing it from sending the reset? I can get similar code working on MacOS under node.js using WebUSB calls, but I suspect it's actually using libusb under the hood... I should say that the device in question has firmware written in Zephyr 3.0 (I wrote a substantial part of it). I haven't gotten resets to work with other devices either, though.
According to https://bugs.chromium.org/p/chromium/issues/detail?id=1189418, it seems like USBDevice.reset() does not work properly on macOS.
Even though a patch was submitted to fix this behaviour, it was reverted due to an expected libusb issue: https://chromium-review.googlesource.com/c/chromium/src/+/2936179
I've pinged the Chromium team at https://bugs.chromium.org/p/chromium/issues/detail?id=1189418#c15. We may want to follow up there.
Related
This may well be a duplicate question, but no answer from an existing question has solved my problem.
I have a WebAPI end point running on my dev machine. I've configured it to run on
.UseUrls("http://localhost:57971", "http://10.0.2.2:57971", "http://192.168.44.1:57971", "http://192.168.1.48:57971", "http://*:57971")
where:
192.168.44.1 is Desktop Adapter #2 on the emulator Networks settings tab
10.0.2.2 is the special address for the Android emulator, as set out in Google's doco (possibly not relevant to Xamarin) and
192.168.1.48 is my local IP address for my dev machine.
I have created a firewall rule permitting connections on TCP port 57971.
I researched this pretty heavily and heeded instructions such as those set out here http://briannoyesblog.azurewebsites.net/2016/03/06/calling-localhost-web-apis-from-visual-studio-android-emulator/
I'm kinda out of ideas. The annoying thing is, it fails silently. There is no exception and the output just basically shows the different threads exiting with code 0. And the application keeps running i.e. the debugging session is not returning the IDE to a "code entry" state. This may suggest that something else its at play here.
The code looks pretty innocuous to me:
protected async Task<T> GetAsync<T>(string url)
where T : new()
{
HttpClient httpClient = CreateHttpClient();
T result;
try
{
var response = await httpClient.GetStringAsync(url);
result = await Task.Run(() => JsonConvert.DeserializeObject<T>(response));
}
catch
{
result = new T();
}
return result;
}
I'm using Visual Studio 2015.
I'm using the Visual Studio emulator https://www.visualstudio.com/vs/msft-android-emulator/
Any idea how I can get wheels on the ground on this thing?
Is there a way to Ping my machine from the emulator?
Thanks
I got this working by using 169.254.80.80 i.e. I added it to the list of urls which the API serves and called that ip address from the Xamarin app.
So, in Program.cs became simple:
.UseUrls("http://localhost:57971", "http://169.254.80.80:57971")
I also had to add it to the bindings element ApplicationConfig file in the hidden .vs folder of the ASP.NET API solution. Not sure why it had to be 169.254.80.80, as that was Desktop Adapter #4.
That got it working.
I have a packaged Chrome app that is trying to read from a serial port. However, everytime I call chrome.serial.getDevices(), it doesn't return (nor does my function get called).
My code is as simple as reacting to a click on my browser action button:
chrome.browserAction.onClicked.addListener(function(tab) {
var onGetDevices = function(ports) {
alert("Devices");
for (var i=0; i<ports.length; i++) {
alert(ports[i].path);
}
}
alert("before");
chrome.serial.getDevices(onGetDevices);
alert("after");
});
The before message gets displayed, but the after one doesn't. I've similarly tried invoking connect() directly, but it too doesn't return.
chrome.serial.connect("/dev/tty.usbserial-AI02KQN0", {bitrate: 9600}, onConnect);
I've read a number of posts that suggest that Chrome on a Mac isn't able to read from the serial port properly, but I'm not sure if I'm suffering from this problem, or something else.
Any ideas? Do I need to move to a Windows machine? Thanks.
man... I should know better. Turns out that I was still shipping it as an extension, not as an app. Once I make it an app, the list of devices are successfully returned.
I have a SignalR hub and two clients (Windows and PCL for Android and iOS). Neither of the clients is able to call some methods on the server. This behaviour is quite odd, since the methods look very similar. Moreover, a colleague of mine is able to call methods I cannot call, and vice versa, does not invoke methods that I invoke with no problems.
Here is an example of a method, which works for me and does not work for my colleague:
public override async Task<bool> RefreshArray(User user, int waitMilis)
{
var cts = new CancellationTokenSource();
try
{
cts.CancelAfter(waitMilis);
await Proxy.Invoke("RefreshArray", user);
return true;
}
catch (Exception ex)
{
OnExceptionOccured(ex);
return false;
}
}
And a method which does not work for me, but works for my colleague:
public override async Task<bool> RequestInformation(User user, Product product, int waitMilis)
{
var cts = new CancellationTokenSource();
try
{
cts.CancelAfter(waitMilis);
await Proxy.Invoke("RequestInformation", user, product);
return true;
}
catch (Exception ex)
{
OnExceptionOccured(ex);
return false;
}
}
Yes, me and my colleague have exactly the same code. And no, there are no typos or different arguments. I have tried to get as much data from the client connection as possible, by setting _connection.TraceLevel = TraceLevels.All; However, I did not get any information on the invoked methods, just on the replies from the hub. When calling RefreshArray, I got exactly the data I requested. When calling RequestInformation, the debugger never even hit the breakpoint in the hub method and the _connection.Trace displayed only this: 11:22:45.6169660 - 7bc57897-489b-49a2-8459-3fcdb8fcf974 - SSE: OnMessage(Data: {})
Has anybody solved a similar issue? Is there a solution?
UPDATE 1
I just realized that I have encountered almost the same issue about a year ago (Possible SignalR bug in Xamarin Android). StackOverflow has also pointed me to a question with almost the same issue (SignalR on Xamarin.iOS - randomly not able to call Hub method), just related to iOS and Azure. However, I got the same proble even outside Xamarin, on Windows Phone 8.1 and and Windows 10 Universal App. Moreover, I am running the server just locally, so it is not an issue od Azure. Is it really possible, that a 2 years old bug has no solution?
UPDATE 2
I have just created a simple console application with SignalR.Client. In the console application every method worked just fine. Amazingly, also the Windows 10 Universal Application started to behave as expected - every hub method was invoked correctly. Windows Phone 8.1 also improved its behaviour (all hub methods invoked). However, every now and then the connection tried to reconnect periodically (for no apparent reason), leading to Connection started reconnecting before invocation result was received. error. The Android application still behaved as before.
So I tried to replicate my previous steps and created another console application, but this time with SignalR.Client.Portable library. To my dissapointment, there was no change in the Android application behaviour.
Next week we will start to test our application on iOS, so I really wonder what new oddities will we encounter.
I have managed to solve the problem (at least so it seems). As it turned out, there is some weird stuff going around, when an application receives an answer from SignalR hub. It seems as if the HubProxy was blocked for a certain period of time on Android, while it drops the connection and starts to reconnect periodically on Windows Phone, not waiting for an asnwer from the hub.
The implementation of RefreshArray on the hub was something like this:
public async Task RefreshArray(User user)
{
await Clients.Caller.SendArray(_globalArray);
await Clients.Caller.SendMoreInformation(_additionalInfo);
}
Because the method sent two methods as an answer, the client Proxy got stuck and each platform handled it in its own unexpected way. The reason why some methods were called on my computer and not on colleagues was, simply, because we had different position of breakpoints, which enabled the application to resolve at least some requests and responses.
The ultimate solution was to add some synchronization into the invokation of methods. Now my hub calls only await Clients.Caller.SendArray(_globalArray);. This is then handled on the client with a ArraySent(string[] array) event, which then subsequently invokes the SendMoreInformation() method on the hub.
I have an application for Motorola MC9500 series that uses the device camera.
I use the following method to init the Imager:
Symbol.Generic.Device MyDevice;
int i = 0;
if (imager == null)
{
MyDevice = (Symbol.Generic.Device)Symbol.Imaging.Device.AvailableDevices.GetValue(0);
for (i = 1; MyDevice != null; i++)
{
if (MyDevice.FriendlyName.Equals("Image Capture Driver for Color Camera"))
break;
MyDevice = (Symbol.Generic.Device)Symbol.Imaging.Device.AvailableDevices.GetValue(i);
}
if (MyDevice == null)
{
MessageBox.Show("Camera não foi encontrada.");
this.Close();
return;
}
imager = new Symbol.Imaging.Imager(MyDevice);
}
It works fine on WM6.1 but not on WM6.5, where the last line throws the following exception:
Failed to create Imager: IMAGE_Open failed: E_IMG_INVALIDDEVICE
According to the manufacturer documentation, this means: "The physical device driver (PDD). DLL did not contain the required entry points.". However, I have all the drivers up-to-date. They can be found on: http://support.symbol.com/support/search.do?cmd=displayKC&docType=kc&externalId=12683&sliceId=&dialogID=469856149&stateId=1%200%20469852171
When I'm running the program, I have no other tasks running, since I thought this could be due to another process locking the camera to itself.
Relevant fact is that the camera doesn't seem to work/start in any other application that uses it. However, they seem to work on my client's device (also WM6.5, same device).
Anyone got any suggestion or idea of why this happens, or how to solve it?
I had the same problem, but mine was caused because I also had a Barcode scanner active, disabling the Barcode scanner fixed this for me.
barcode2.Disable()
You have to download and install a CAB to enable second source camera from motorola site (SPR23173).
I had this problem with a Motorola MC75A. Turns out it was the Datawedge application that was also installed on the device that was stopping it from working correctly. The camera and the barcode scanner appear to be kind of linked. You can only use one at once and as the DataWedge was already running, my code/project was producing the IMAGE_Open failed: E_IMG_INVALIDDEVICE. Simply going into DataWedge and stopping the process fixed this instantly.
I installed node.js from http://nodejs.org/#download, v0.6.6. I am using Windows 7 32-bit.
I've been going through various tuts online, and want to experiment while doing so, but I cannot seem to get node.js working. Node will run my .js file, but any request from the browser times out.
Here is a typical Hello World example that does not work:
var http = require('http');
http.createServer(function (req, res) {
res.writeHead(200, {'Content-Type': 'text/plain'});
res.end('Hello World\n');
}).listen(1337);
Pointing my browser at 127.0.0.1:1337 or localhost:1337 does not work. The request from the browser times out. I've also tried listen(1337,'0.0.0.0') and listen(1337,'127.0.0.1').
I know the server is running; if I CTRL+C and stop node, the browser immediately comes back with ERR_CONNECTION_RESET.
I also tried running the code in this gist, which will not work: https://gist.github.com/1339846. I end up with the console output "Listening!" and then nothing else.
Furthermore, I have tried different ports, and my firewall is off via
netsh firewall set opmode mode=disable
I tried with firewall totally disabled, and the service stopped. If I check connections using netstat -noa, I can see node has a bunch of connections opened for the browsers, all in state CLOSE_WAIT. So it looks like connections are happening, but node.js just isn't working.
The callback function that is supposed to be initiated by a request never executes - I sprinkled some console.log statements in various areas, and they all execute except any in the callback.
I uninstalled, re-installed, tried a couple previous builds, restarted my machine...nothing.
Any help is appreciated!
UPDATE: I have just about given up. I've tried everything I can think of, and it ended up being easier to run node.js in an instance of Ubuntu in VirtualBox than grasp at straws.
!!!!!! Same problem happened for me....
Here is a solution which I have yet to find anywhere:
Look in Windows Firewall with Advanced Security and see if Evented I/O for V8 JavaScript is blocked or appears two times.
If so unblock it and delete the duplicated entry. If you install/uninstall/install nodeJs, there will be 2 entries.
Also when node first runs the Window Firewall dialog opens asking if you want to allow node to have firewall access. If you press "No" or just close the window without asking, it will create Evented I/O for V8 JavaScript AND IT WILL BE BLOCKED.
I ran into the same problem and after reading through the documentation, I unexpectedly ran into what I believe is the solution. In my instance I was noticing that the incoming requests WERE being delivered to node, but the response was never having its 'end' event triggered. So altering incoming firewall rules in windows did not seem to be related to the problem.
So, http.createServer takes in a single argument - a function which should include a request and response parameter. The request parameter seemed to be where the problem lay. The request parameter is an instance of http.incomingMessage. This class only had like one event type, but it was itself also an implementation of Stream.Readable, which is where I found the 'end' event that wasn't triggered. Really for no other reason that to just test which was the first event not triggered, I just added a listener for another type of event ('readable'), and only added a console.log line to it which made the whole thing work.
So the code looks simply something like this:
var http = require("http");
http.createServer(function (request, response) {
console.log('request');
request.on('readable', function(){
console.log('request readable');
});
request.on("end", function () {
console.log('request end');
response.writeHead(200, {
'Content-Type': 'text/plain'
});
response.end('Hello HTTP!');
});
}).listen(8080);
The above code works, whereas the earlier version below without a 'readable' event listener does not ever respond:
var http = require("http");
http.createServer(function (request, response) {
console.log('request');
request.on("end", function () {
console.log('request end');
response.writeHead(200, {
'Content-Type': 'text/plain'
});
response.end('Hello HTTP!');
});
}).listen(8080);
I am not sure why this works except for a little clue in the documentation which reads:
In some cases, listening for a 'readable' event will cause some data
to be read into the internal buffer from the underlying system, if it
hadn't already.
I just tried it and it works for me. Make sure you are not blocking node with your firewall.
I am using Windows 7 32-bit.
What edition of Windows 7 are you using? Eg. Home Premium, Professional, Ultimate?
A thread on the npm github project mentions similar symptoms while installing nodejs modules using npm, and comments seem to narrow it down to being caused by Windows 7 Professional. It being 32/64-bit doesn't seem to matter.
I am having both the problem you describe, as well as the npm installation problem, and am running on Windows 7 Professional 64-bit.
Using XPMode (a workaround mentioned in the npm thread) has allowed me to workaround both of these issues. Although, I suppose this is just a more Windows-y version of your use of Ubuntu in VirtualBox.
Other workarounds tried without success:
Make/run a Debug build of v0.6.6
Make/run a Debug build of v0.6.5 (actually crashed in startup)
Set various Compatability Modes on the installed node.exe
Prepackaged Windows installer of v0.6.5
Go to "Control Panel\All Control Panel Items\Windows Firewall\Allowed
Programs"
Click Allow Programs
select nodejs from the list.
This fixed all the problems for me
I was having the same problem with this code (Http Server example from this link: http://net.tutsplus.com/tutorials/javascript-ajax/node-js-for-beginners/)
var http = require("http");
http.createServer(function (request, response) {
request.on("end", function () {
response.writeHead(200, {
'Content-Type': 'text/plain'
});
response.end('Hello HTTP!');
});
}).listen(8080);
I tried windows 7 64-bit version, windows XP virtual machine, ubuntu virtual machine ... nothing! It only worked after I commented the "request.on" line. Your example (which doesn't have this line) worked fine for me. I'm using the latest stable build from node.js (v0.10.18 for windows or linux). Hope this helps anyone having trouble with this.