driverNames in windows
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
driverNames in windows
I have tons of experience with HyperCard and SuperCard on the Mac, but I'm just jumping in to LiveCode for cross platform development. I'm stuck already.
On a Mac I can use driverNames to get a list of serial drivers on which I can use open, close, read from, write to, etc. What is the Windows version of driverNames? That is, how do I get a list of available serial drivers?
Thanks!
Hutch
On a Mac I can use driverNames to get a list of serial drivers on which I can use open, close, read from, write to, etc. What is the Windows version of driverNames? That is, how do I get a list of available serial drivers?
Thanks!
Hutch
-
- Livecode Opensource Backer
- Posts: 89
- Joined: Mon Jul 19, 2010 6:59 am
- Location: Illinois, USA
Re: driverNames in windows
Search "COM1:" in the dictionary. Is that what you're looking for?
Re: driverNames in windows
deebee,deebee wrote:Search "COM1:" in the dictionary. Is that what you're looking for?
Thanks for the reply. That's part of what I'm looking for
![Wink ;)](./images/smilies/icon_wink.gif)
I want to present the user with a list of active ports from which to choose. For Mac there is a function (driverNames), that returns a list of active serial port drivers (or one can read the file "/dev/tty").
Is there something similar for Windows?
I have very limited experience on Windows machines, but I was just using Digi's XCTU to configure some XBee modules, and it presents a list of the active COM ports, so I'm guessing there's probably an OS function call.
If not, I suppose I could use a brute force method; trying "open driver" on every COM port and examining the result. But I don't know how many possible COM ports there are. LiveCode's library gives conflicting info.
The library entry for openFile says: "specify either 'COM1:', 'COM2:', or up to 'COM9:'." and "Note: On windows, it is imperative not to name a file with one of the reserved device names: CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8 and LPT9. Also do not use these names followed by an extension, for example, NUL.tx7."
... suggesting that there are COMn ports 1 through 9. However, the entry for COMn says: "Tip: You can access any COM port available on the system by using the appropriate index, e.g. COM5:, COM10: etc."
... suggesting that there are at least 10 COM ports.
Hutch
-
- Posts: 66
- Joined: Fri Feb 05, 2010 7:31 pm
Re: driverNames in windows
Hi,
Someone else might be able to point you in the direction of the right LC commands to use, but I know that the registry in windows stores the currently active com ports.
Type Regedit at a command prompt, and then look for the following key "HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM" this will list all the active com ports on your machine. I'm sure you must be able to read this into LC
What would be great would be to have a cross platform function that returns a list of the serial driver names, which can then be used with the "open" command.
Hope the above helps
Cheers
Martin
Someone else might be able to point you in the direction of the right LC commands to use, but I know that the registry in windows stores the currently active com ports.
Type Regedit at a command prompt, and then look for the following key "HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM" this will list all the active com ports on your machine. I'm sure you must be able to read this into LC
What would be great would be to have a cross platform function that returns a list of the serial driver names, which can then be used with the "open" command.
Hope the above helps
Cheers
Martin
-
- Livecode Opensource Backer
- Posts: 89
- Joined: Mon Jul 19, 2010 6:59 am
- Location: Illinois, USA
Re: driverNames in windows
A windows PC can support 256 serial connections, but I'd assume LC only will handle nine, since that is all the docs cover. Maybe that COM10 was a typo???hutchfx wrote:If not, I suppose I could use a brute force method; trying "open driver" on every COM port and examining the result. But I don't know how many possible COM ports there are. LiveCode's library gives conflicting info.
If LC supports all of them, you could probably very easily check all 256 in a repeat for and it should only take about a second to check all of them.
![Smile :)](./images/smilies/icon_smile.gif)
Last edited by deebee on Wed Apr 13, 2011 4:58 am, edited 1 time in total.
-
- Livecode Opensource Backer
- Posts: 89
- Joined: Mon Jul 19, 2010 6:59 am
- Location: Illinois, USA
Re: driverNames in windows
Ok, this forced me into experimenting with a repeat, so thank you for affording me the opportunity to gain experience!!
This only takes a split second and seem to work as it should!
![Very Happy :D](./images/smilies/icon_biggrin.gif)
Code: Select all
on mouseUp
local tSerialCheck
local tOpenSerial
put empty into tOpenSerial
repeat with tNum = 1 to 256
put "COM" & tNum & ":" into tSerialCheck
open file tSerialCheck for read
if the result is not "can't open that file" then put tOpenSerial & tSerialCheck & CR into tOpenSerial
end repeat
if tOpenSerial is empty then put "No open serial ports!" into tOpenSerial
answer "The following serial ports are open:" & CR & tOpenSerial with "OK"
end mouseUp
-
- Posts: 66
- Joined: Fri Feb 05, 2010 7:31 pm
Re: driverNames in windows
Hi DeeBee,
I tested out your code and it indeed works well, although it reported 14 more comm ports than I expected. Looking at the registry entry I mentioned earlier it listed the drivers as being \Device\Vcom see the attached screen shot.
I did google and found this article http://c-scope.blogspot.com/2007/10/ser ... ouble.html I just mention this I case you come across similar problems.
Cheers
Martin
I tested out your code and it indeed works well, although it reported 14 more comm ports than I expected. Looking at the registry entry I mentioned earlier it listed the drivers as being \Device\Vcom see the attached screen shot.
I did google and found this article http://c-scope.blogspot.com/2007/10/ser ... ouble.html I just mention this I case you come across similar problems.
Cheers
Martin
- Attachments
-
- SerialComm.jpg (95.95 KiB) Viewed 11171 times
-
- Livecode Opensource Backer
- Posts: 89
- Joined: Mon Jul 19, 2010 6:59 am
- Location: Illinois, USA
Re: driverNames in windows
The fact that the code reported back that many open ports is at least a good indication that LC supports more than the documented 1 thru 9!mhoneywill wrote:although it reported 14 more comm ports than I expected.
Also, thanks for the link!
-
- Posts: 66
- Joined: Fri Feb 05, 2010 7:31 pm
Re: driverNames in windows
I've asked the question of RunRev support and have tested it myself LC does support up to 255 com ports, under windows at least.
You may have noticed in my screenshot com ports Com100,101,102,103,110,111,112,113 these are back to back com ports created with comocom see http://com0com.sourceforge.net/ great tool for development work
Cheers
Martin
You may have noticed in my screenshot com ports Com100,101,102,103,110,111,112,113 these are back to back com ports created with comocom see http://com0com.sourceforge.net/ great tool for development work
Cheers
Martin
Re: driverNames in windows
Thanks for jumping in on this!
deebee:
I've put version of your code into my project, but I won't be able to test it until I meet again with a friend who has a windows machine. BTW... I added "close file tSerialCheck" after a successful open file.
Martin:
Your post got me thinking, so I searched the liveCode library for "registry" and found:
"queryRegistry
Type: function
Syntax:
the queryRegistry of keyPath
queryRegistry(keyPath[,typeVariable])"
this looks like it would be the proper way to get the open ports.
Can someone developing on a Windows machine test this?
Thanks!
Hutch
deebee:
I've put version of your code into my project, but I won't be able to test it until I meet again with a friend who has a windows machine. BTW... I added "close file tSerialCheck" after a successful open file.
Martin:
Your post got me thinking, so I searched the liveCode library for "registry" and found:
"queryRegistry
Type: function
Syntax:
the queryRegistry of keyPath
queryRegistry(keyPath[,typeVariable])"
this looks like it would be the proper way to get the open ports.
Can someone developing on a Windows machine test this?
Thanks!
Hutch
Re: driverNames in windows - success through brute force
Success through brute force.
I borrowed a Windows laptop and tested my project. It successfully gets the list of active serial drivers by looping through all 255 ports, opening each in turn, then checking the result. It then puts the list into a popup for selection:
A button called "connection" calls this:
I also tried the queryRegistry function:
Running this on my Mac, the function returned empty, and the result was "not supported". This is slightly different from what the liveCode library claims. It says that the function returns "not supported".
Running this on the Windows machine, both the return and the result were empty.
I could only make changes on my Mac, save as an executable, then transfer it to the Windows machine to try it (the antithesis of liveCode, and a big pain), so I didn't do any further testing.
I borrowed a Windows laptop and tested my project. It successfully gets the list of active serial drivers by looping through all 255 ports, opening each in turn, then checking the result. It then puts the list into a popup for selection:
Code: Select all
on doDriverList
put empty into myDriverNames
put empty into myDriverList
switch the platform
case "MacOS"
put the driverNames into myDriverNames
-- MacOS returns comma delimeted lists
repeat with lineNumber = 1 to the number of lines of myDriverNames
repeat with itemNumber = 1 to the number of items of line lineNumber of myDriverNames
put (item itemNumber of line lineNumber of myDriverNames) & return after myDriverList
end repeat
end repeat
if myDriverList is not empty then delete last char of myDriverList -- remove last CR
break
case "Win32"
put empty into portName
repeat with portNumber = 1 to 256
put "COM" & portNumber & ":" into portName
open file portName for read
if the result is not "can't open that file" then
put portName & return after myDriverList
close file portName
end if
end repeat
if myDriverList is not empty then delete last char of myDriverList -- remove last CR
break
default
exit doDriverList
break
end switch
set the text of button "Select a serial driver" to "Select a serial driver:" & return & mydriverlist
end doDriverList
Code: Select all
on doConnection
global gMySerialDriver
if the label of button "Connection" is "Connect" then
put the label of button "select a serial driver" into gMySerialDriver
switch the platform
case "MacOS"
if (char 1 of gMySerialDriver is not "/") then exit doConnection
break
case "Win32"
if ("COM" is not in gMySerialDriver) then exit doConnection
break
end switch
open driver gMySerialDriver for text update
set the label of button "Connection" to "Disconnect"
set the toolTip of button "Connection" to "Close the serial connection"
else
close driver gMySerialDriver
set the label of button "Connection" to "Connect"
set the toolTip of button "Connection" to "Open the serial connection"
end if
end doConnection
Code: Select all
on mouseUp
put queryRegistry("HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM") into field "my field"
put return & the result after field "my field"
end mouseUp
Running this on the Windows machine, both the return and the result were empty.
I could only make changes on my Mac, save as an executable, then transfer it to the Windows machine to try it (the antithesis of liveCode, and a big pain), so I didn't do any further testing.
-
- Posts: 66
- Joined: Fri Feb 05, 2010 7:31 pm
Re: driverNames in windows
Hi Hutch,
Could you post your .Livecode file and I'll see if I can do some more testing on windows. I'll also see if I can get it to work on Linux too.
Cheers
Martin
Could you post your .Livecode file and I'll see if I can do some more testing on windows. I'll also see if I can get it to work on Linux too.
Cheers
Martin
Re: driverNames in windows
Martin
I tried to upload the livecode file, but got the error message "The extension livecode is not allowed."
I thought maybe they hadn't changed this since the name change, so I tried it with ".rev", but got the same error.
Seems odd.
Hutch
I tried to upload the livecode file, but got the error message "The extension livecode is not allowed."
I thought maybe they hadn't changed this since the name change, so I tried it with ".rev", but got the same error.
Seems odd.
Hutch
-
- Posts: 66
- Joined: Fri Feb 05, 2010 7:31 pm
Re: driverNames in windows
Hi Hutch,
Hmm it didn't work for me either, try emailing it directly to me at runrev dot livecode at gmail dot com and we'll see if that works.
Do you use Dropbox that's a good way of sharing files by putting them in the public folder are sharing the link to the file with other people, it works on windows and Mac.
Here is a link that you can use to sign up that will give both of us an extra 250Mb of storage http://db.tt/5nQhIBq
Cheers
Martin
Hmm it didn't work for me either, try emailing it directly to me at runrev dot livecode at gmail dot com and we'll see if that works.
Do you use Dropbox that's a good way of sharing files by putting them in the public folder are sharing the link to the file with other people, it works on windows and Mac.
Here is a link that you can use to sign up that will give both of us an extra 250Mb of storage http://db.tt/5nQhIBq
Cheers
Martin
Re: driverNames in windows
I think you can attach zip files ?? so maybe if you tried zipping it first it would upload. Maybe.
I think you may have a problem using simple registry queries to do what you want. It's been a long time since I delved with livecode (or Runtime Revolution as it was, when I did most of the tinkering in that area - before the RunRev moniker even) so I'm not sure whether I am imagining or things have changed since then...
Using will not yield a useful value because it is the key name, not a key value.
From the docs, "If the keyPath ends in "\", the value returned is the default value for the key." So(with a trailing backslash) will provide the single key value in the (Default) subkey name under the keyPath. Which is almost certainly going to be (value not set).
For years I have only used specific key names to set and interrogate particular key values, so here is where my memory is probably at fault, but I could persuade myself that it used to be possible to have the keyPath defined with a trailing slash and the returned value was a list of the subkey names, not "the default" (almost invariably useless) value. I remember helping someone with a series of things involving registry AND WMI interrogation via PM on this forum, before the PM facility was locked. (Wonder if those PMs are still historically available in the background if temporary access were granted again?) Anyway I may well have called shell commands or WMI vbscript objects to obtain the list of subkey names, it seems likely to me now...
I think you may have a problem using simple registry queries to do what you want. It's been a long time since I delved with livecode (or Runtime Revolution as it was, when I did most of the tinkering in that area - before the RunRev moniker even) so I'm not sure whether I am imagining or things have changed since then...
Using
Code: Select all
put queryRegistry("HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM") into field "my field"
From the docs, "If the keyPath ends in "\", the value returned is the default value for the key." So
Code: Select all
put queryRegistry("HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM\") into field "my field"
For years I have only used specific key names to set and interrogate particular key values, so here is where my memory is probably at fault, but I could persuade myself that it used to be possible to have the keyPath defined with a trailing slash and the returned value was a list of the subkey names, not "the default" (almost invariably useless) value. I remember helping someone with a series of things involving registry AND WMI interrogation via PM on this forum, before the PM facility was locked. (Wonder if those PMs are still historically available in the background if temporary access were granted again?) Anyway I may well have called shell commands or WMI vbscript objects to obtain the list of subkey names, it seems likely to me now...