driverNames in windows

Deploying to Windows? Utilizing VB Script execution? This is the place to ask Windows-specific questions.

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

hutchfx
Posts: 37
Joined: Sat Apr 09, 2011 5:38 am

driverNames in windows

Post by hutchfx » Sat Apr 09, 2011 6:08 am

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

deebee
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 89
Joined: Mon Jul 19, 2010 6:59 am
Location: Illinois, USA

Re: driverNames in windows

Post by deebee » Sat Apr 09, 2011 7:26 am

Search "COM1:" in the dictionary. Is that what you're looking for?

hutchfx
Posts: 37
Joined: Sat Apr 09, 2011 5:38 am

Re: driverNames in windows

Post by hutchfx » Mon Apr 11, 2011 8:48 am

deebee wrote:Search "COM1:" in the dictionary. Is that what you're looking for?
deebee,

Thanks for the reply. That's part of what I'm looking for ;)

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

mhoneywill
Posts: 66
Joined: Fri Feb 05, 2010 7:31 pm

Re: driverNames in windows

Post by mhoneywill » Mon Apr 11, 2011 4:20 pm

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

deebee
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 89
Joined: Mon Jul 19, 2010 6:59 am
Location: Illinois, USA

Re: driverNames in windows

Post by deebee » Tue Apr 12, 2011 2:47 am

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.
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???

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. :)
Last edited by deebee on Wed Apr 13, 2011 4:58 am, edited 1 time in total.

deebee
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 89
Joined: Mon Jul 19, 2010 6:59 am
Location: Illinois, USA

Re: driverNames in windows

Post by deebee » Tue Apr 12, 2011 3:49 am

Ok, this forced me into experimenting with a repeat, so thank you for affording me the opportunity to gain experience!! :D

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
This only takes a split second and seem to work as it should!

mhoneywill
Posts: 66
Joined: Fri Feb 05, 2010 7:31 pm

Re: driverNames in windows

Post by mhoneywill » Wed Apr 13, 2011 6:56 pm

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
Attachments
SerialComm.jpg
SerialComm.jpg (95.95 KiB) Viewed 11171 times

deebee
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 89
Joined: Mon Jul 19, 2010 6:59 am
Location: Illinois, USA

Re: driverNames in windows

Post by deebee » Thu Apr 14, 2011 6:13 am

mhoneywill wrote:although it reported 14 more comm ports than I expected.
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!

Also, thanks for the link!

mhoneywill
Posts: 66
Joined: Fri Feb 05, 2010 7:31 pm

Re: driverNames in windows

Post by mhoneywill » Fri Apr 15, 2011 2:28 pm

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

hutchfx
Posts: 37
Joined: Sat Apr 09, 2011 5:38 am

Re: driverNames in windows

Post by hutchfx » Mon Apr 18, 2011 7:18 am

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

hutchfx
Posts: 37
Joined: Sat Apr 09, 2011 5:38 am

Re: driverNames in windows - success through brute force

Post by hutchfx » Thu Apr 21, 2011 9:30 am

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:

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
A button called "connection" calls this:

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
I also tried the queryRegistry function:

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 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.

mhoneywill
Posts: 66
Joined: Fri Feb 05, 2010 7:31 pm

Re: driverNames in windows

Post by mhoneywill » Thu Apr 21, 2011 11:16 am

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

hutchfx
Posts: 37
Joined: Sat Apr 09, 2011 5:38 am

Re: driverNames in windows

Post by hutchfx » Fri Apr 22, 2011 2:42 am

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

mhoneywill
Posts: 66
Joined: Fri Feb 05, 2010 7:31 pm

Re: driverNames in windows

Post by mhoneywill » Fri Apr 22, 2011 9:06 am

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

SparkOut
Posts: 2862
Joined: Sun Sep 23, 2007 4:58 pm

Re: driverNames in windows

Post by SparkOut » Fri Apr 22, 2011 10:04 am

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

Code: Select all

put queryRegistry("HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM") into field "my field"
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

Code: Select all

put queryRegistry("HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM\") into field "my field" 
(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...

Post Reply

Return to “Windows”