No winnus error with no access #4
Conversation
ensure that winnus has hardware that can be used signoff [email protected]
Sign off Owen Brotherwood
|
Did you see my comment about |
|
Sorry: didn't see the comment Bluetooth adapter available Bluetooth adapter NOT available: "Error: DevicePaths" |
|
Huh, odd. All I can think is this is actually comparing to see if the length is 0 - in which case this will also fail if you don't have any available BLE devices found. Were you able to test that? |
|
Examine the two screen shots, taken one after the other. A simple setup to test the if statement. |
|
Hmm, why isn't it on the PR: looking It was a long night the other night doing the research :) |
|
Multiple PR's with also some wip are no fun late at night. Let's get this Pulled as I have found other stuff that is "interesting" plus corrections to doc: I have too many branches to handle safely just now |
|
@gfwilliams I need this pulled.
Surrounding issues concerning pre NTDDI_WINBLUE
Possible interesting issues for pre NTDDI_WINBLUE need to be analysed to see if relevant for Espruino IDE My main concern when starting with Espruino was the IDE as it was impossible to create from source, learning curve and dependencies. Yours very sincerely, |
|
Is this tested when the adaptor is enabled but there are no Bluetooth devices available? Also, is this tested on EspruinoTools/EspruinoWebIDE to see if it doesn't completely break them when no adaptor is available? Because as far as I can see from the code, this will cause an exception in the Web IDE/EspruinoTools if no devices are found - which will crash it rather than causing it just to keep polling for more devices as it should. So I can't pull this in, because it'll break every 'real' piece of code that uses it |
|
The tests so far with EspruinoTools and IDE show, as far as I remember, no ports found as a result of the winnus alteration or just access to a usb dependant on test scenario
usb notes here as usb was the biggest issue and need to check my notes
node-usb/node-usb#162 (comment) Basically, one get's to about this picture (note that this picture is after the one below as I am trying to document how to get usb to behave in the setup I have for Windows 10
Pull altogether with sweet spot of nwjs SDK at intersection of node v7 and released nwjs to minimise gyp work reference https://nwjs.io/versions.json Documentation: And probably some more issues along the way. npm pack of all the gyp modules I remember seeing and EspurinoTools (espurino) from current repos with winnus-0.0.3 An example of usb hell that I have to look into my note for: ie nw-gyp is probably required at this stage to fix up usb. This is NOT a test of the winnus alteration, just a way I can now document the steps needed to achieve the IDE, followed by bluetooth available/unavailable to Windows based IDE
👎 node-usb/node-usb#169 (comment) while usb/nw.js is in progress, I needed a little sucess with a non nw.js installation: ie pure node-gyp and no nw-gyp possible problems. using a set of cherry picked cloned native repros, npm pack: Bluetooth available to NTDDI_WINBLUE No Bluetooth available to NTDDI_WINBLUE Zadig on Windows 10 with npm installation of cherry picked git repros (tgz's) but NOT my winnus
Zandig Windows 10 with cherry picked repos AND npm install \source\npm\winnus-0.0.3.tgz What does this show?
As the examples are part of the npm install \source\npm\winnus-0.0.3.tgz I can just hop into the directory for winnus examples and do an ordinary npm install to get the released winnus and now with npm install \source\npm\winnus-0.0.3.tgz Conclussion ? but I haven't gone thru the collection of results above yet: I was just hammering the keyboard to get something to look at. However:
|
|
@gfwilliams However, my test is based on one assumption, that var paths = winnus.getDevicePaths(); gives a list of paths to adapters present and that the addition of adapters after program start is not supported: ie no plug and play of adapters after application start. If this is the issue for not liking the test, no plug and play of adapters after program start, that is ok and I can withdraw the PR. However, for the time being, I think it is the best way forward if the lack of plug and play of adapters after application start can be accepted in order to find the best support for static adapters in Windows 7 - 10. 'tis a long time since I did c++ and I don't really want to refresh the experience as getting an IDE to work for Windows 7 - 10 is perceived to be a problem. |
|
I think there might be some confusion between 'adaptors' and 'devices'? I'm pretty sure So if you call it with a working BLE adaptor but no Pucks in range, it should return an empty list - not error. And yes - it gets called repeatedly for plug&play - so if you bring a Puck within range or add a battery to a Puck that no longer had one (but that Windows knows about) while the Web IDE is showing that 'devices' screen then it'll auto-update - like it does with USB devices. |
|
yep: possible confusion between adapters (the physical device in the host computer) and devices (the devices that are connectable to by the adapter) ... or something along that line: terms used for rest of this comment. I try and make a little test program for winnus that continually tries for devices (puck.js) with puck.js off at program start and try and get the test ok. Tests for adapter
With a bluetooth device paired, but not switched on, winnus does not throw:
With no bluetooth device paired (switched on/off possible device is irrelevant here), winnus does throw:
ie at the present time, no plug and play for a device that is not paired at application start There is something to think about here: devices available, but no connect ... What is bluetooth, and how to test for an adapter that allows for "plug and play" of a device, ie it get's paired after application with sufficient tests at program start to ensure the possibility of "plug and play" of a device and/or adapter. "NTDDI_WINBLUE" winnus 0.0.3 allows for
ie
Context of possible tests for as yet unknown methods for:
And the choice of how much plug and play is needed contra possible confussion for user with choice of device but no connect and no information as to the reason Circles:
puck.js with no battery Connection failed pop up bottom right: hard to catch
puck.js on but not paired no information to user to pair: user sits and wonders what is wrong, starts RTBM (maybe) or forum or gives up ... It is possible the user comes from a non-windows machine and expects some "pair" dialog aka. chrome on some platforms.
Bluetooth switched off (accidental fly mode on a laptop as a user case) No dialog: what does the application expect to indicate ie "I have some USB's for you, but did you expect bluetooth? Check bluetooth turned on and pair the device please" puck.js is sleek and a clear consumer product for "whatever is wanted": typical Espruino hobbyists possibly know the drill, although until puck.js, experience with bluetooth as the only connection method is possibly limited and we all make mistakes
|
|
@gfwilliams winnus 0.0.3 may stop plug and play for adapter device if one suceeds with building the IDE from source, however, without a clear throw list, the applications leave the user "in the dark". https://docs.microsoft.com/en-us/uwp/api/Windows.Devices.Enumeration.DeviceInformationKind |
|
What I'd like is:
But this is what happens already If you look at the C++ source you'll see that getDevicePaths should throw exceptions if stuff goes wrong: https://github.com/espruino/winnus/blob/master/cpp/winnus.cpp#L108 If it's not throwing an exception at some point but it should be then yes - issue a PR with an exception throw at that point in the C++ code - but what you're doing is just circumventing the carefully written error handling code with a nasty hack in JS - and in the process throwing an exception when one shouldn't be thrown. If you don't have a USB COM port plugged into your PC, which most people won't, then you see this:
Which points you to a troubleshooting guide which helps you out of you have problems. Sorry, but closing this - it's wasting a huge amount of my time. |
|
No comment needed for my reply. In terms of the context for a Windows 10 machine: with definitions as the cut and paste from the Windows Device Manager
0.0.2 0.0.3
The result is the same: winnus does not load, however the 0.0.3 allows for a possible start for ensuring applications that use winnus to obtain information as to why and the perceived need to go into c++ to improve the messages to higher level applications, with winnus.js being the readable part of the stack before delving into c++.
Although I have to double check this, on Windows 10 laptops, it seems that I have a result for USB. |
|
At a guess, the com3 port is the GPS of the Sierra Wireless EM7345 4G LTE (combined device). Other laptops may have other USB COM ports that are not immediately obvious unless one takes the time to explore it's function: ie it is not allways the user choice which dictates the choice of device that pops up, and is quite har to create any application guards for.
|
|
Maybe the Web IDE just always shows the 'troubleshooting' link regardless? I think it's rare that devices have a USB Serial port pre-installed in them though.
Ideally the devices could be reported with a flag |
if the link is to good doc, then yes, some "?" or other icon for "in the face" possibility for help.
I wrote earlier:
What I mean with this is, I can program when I have mapped out 10% of the time to this: the other 90% of the time is finding some total perspective over the work to be done. However, c++ code contribution from me would probably be "interesting" as c++ is a long time ago for me (but I am quiet good at cut and paste) The actual code/doc contribution is preferably with atomic PR's that result in step by step improvements rather than one big "solve everything PR" as that is not going to happen. |
Fixes: espruino/EspruinoTools#57
Impementation:
Very simple test of var paths = winnus.getDevicePaths(); to ensure that winnus is truly active.