I'm starting to program an Access database to interact with a hardware
RNG (Random Number Generator) made by Orion connected to a COM port. I
plan to do a quickie version using the MSComm OCX control and then a
version using the CreateFile and ReadFile API functions. Has anyone
already done something like this so that I don't have to start from
scratch?

Merci à l'avance,
James A. Fortune

On 5 Apr 2005 12:53:45 -0700, jimfortune@compumarc.com wrote:

I think it's VERY likely that MSComm uses those APIs under the hood.
There is no point in you rewriting it.

-Tom.

[color=blue]
>I'm starting to program an Access database to interact with a hardware
>RNG (Random Number Generator) made by Orion connected to a COM port. I
>plan to do a quickie version using the MSComm OCX control and then a
>version using the CreateFile and ReadFile API functions. Has anyone
>already done something like this so that I don't have to start from
>scratch?
>
>Merci à l'avance,
>James A. Fortune[/color]

Tom van Stiphout wrote:[color=blue]
> On 5 Apr 2005 12:53:45 -0700, jimfortune@compumarc.com wrote:
>
> I think it's VERY likely that MSComm uses those APIs under the hood.
> There is no point in you rewriting it.
>
> -Tom.[/color]

You are correct that MSComm very likely uses those APIs. The problem
with the MSComm OCX, as I see it, is that certain software such as
Visual Basic 6 or Visual Studio must be installed in order to supply a
license required for its use. Since I have a legal copy of Visual
Studio it only becomes an issue if others try to use the OCX version.
It is still be useful for me to try the OCX first unless someone shares
some API code. It would even save me time to see some sample MSComm
code for this device although I've almost got that working now.

James A. Fortune

On 5 Apr 2005 20:58:43 -0700, jimfortune@compumarc.com wrote:

Just for kicks I ran Dependency Walker from the VS Tools folder on the
OCX, and indeed it uses those APIs, and a scary large number of other
APIs as well. I wouldn't hazard to rewrite it.

The way I understand the licensing, the end user does NOT need to have
VB or VS installed. You buying it gives you the right to redistribute
several files, including this one.

-Tom.

[color=blue]
>Tom van Stiphout wrote:[color=green]
>> On 5 Apr 2005 12:53:45 -0700, jimfortune@compumarc.com wrote:
>>
>> I think it's VERY likely that MSComm uses those APIs under the hood.
>> There is no point in you rewriting it.
>>
>> -Tom.[/color]
>
>You are correct that MSComm very likely uses those APIs. The problem
>with the MSComm OCX, as I see it, is that certain software such as
>Visual Basic 6 or Visual Studio must be installed in order to supply a
>license required for its use. Since I have a legal copy of Visual
>Studio it only becomes an issue if others try to use the OCX version.
>It is still be useful for me to try the OCX first unless someone shares
>some API code. It would even save me time to see some sample MSComm
>code for this device although I've almost got that working now.
>
>James A. Fortune[/color]

Tom van Stiphout wrote:[color=blue]
> On 5 Apr 2005 20:58:43 -0700, jimfortune@compumarc.com wrote:
>
> Just for kicks I ran Dependency Walker from the VS Tools folder on[/color]
the[color=blue]
> OCX, and indeed it uses those APIs, and a scary large number of other
> APIs as well. I wouldn't hazard to rewrite it.
>
> The way I understand the licensing, the end user does NOT need to[/color]
have[color=blue]
> VB or VS installed. You buying it gives you the right to redistribute
> several files, including this one.
>
> -Tom.[/color]

Tom,

Thanks for the excellent information. You went beyond the call :-).
Exactly how would I redistribute the file? When I copy the OCX to a
machine that doesn't have the appropriate software installed Access
(A2K I believe) won't even let me use it.

James A. Fortune

On 6 Apr 2005 00:51:17 -0700, jimfortune@compumarc.com wrote:

Typically you would use a setup generator to do that. MSFT has a
special developer toolkit (the actual name is "convenienly" different
for each version) for Access that includes one. VB has the Package &
Deployment Wizard. Then there are commercial products such as
InstallShield.
Poor man's version: copy the ocx to the Windows\System32 folder, and
run regsvr32.exe on it.

-Tom.


[color=blue]
>Tom van Stiphout wrote:[color=green]
>> On 5 Apr 2005 20:58:43 -0700, jimfortune@compumarc.com wrote:
>>
>> Just for kicks I ran Dependency Walker from the VS Tools folder on[/color]
>the[color=green]
>> OCX, and indeed it uses those APIs, and a scary large number of other
>> APIs as well. I wouldn't hazard to rewrite it.
>>
>> The way I understand the licensing, the end user does NOT need to[/color]
>have[color=green]
>> VB or VS installed. You buying it gives you the right to redistribute
>> several files, including this one.
>>
>> -Tom.[/color]
>
>Tom,
>
>Thanks for the excellent information. You went beyond the call :-).
>Exactly how would I redistribute the file? When I copy the OCX to a
>machine that doesn't have the appropriate software installed Access
>(A2K I believe) won't even let me use it.
>
>James A. Fortune[/color]

Tom van Stiphout wrote:[color=blue]
> On 6 Apr 2005 00:51:17 -0700, jimfortune@compumarc.com wrote:
>
> Typically you would use a setup generator to do that. MSFT has a
> special developer toolkit (the actual name is "convenienly" different
> for each version) for Access that includes one. VB has the Package &
> Deployment Wizard. Then there are commercial products such as
> InstallShield.
> Poor man's version: copy the ocx to the Windows\System32 folder, and
> run regsvr32.exe on it.
>
> -Tom.[/color]

Perhaps repeating it again will help. The Poor man's version you give
and probably the others WILL NOT WORK with the MSComm OCX. Windows
won't allow you to register it unless it detects that you have the
proper software installed. Perhaps the toolkit or the Deployment
Wizard you mention somehow gets around this. I'll try the Deployment
Wizard first. The A97 developer toolkit is the only one I have. BTW,
has anyone written code to read this device?

James A. Fortune

The phrase 'veni, vidi, vici' was probably pronounced 'weeni, weedi,
weechi' but pronouncing it that way today seems to produce the opposite
of the intended effect. -- Wayne Noss

BTW: I lean towards vici = weeki. Caesar was probably pronounced 'Caee
SAAR' (syllables rhyme with sky and car) and produced the words 'tsar'
and 'czar.'

jimfortune@compumarc.com wrote:[color=blue]
> Tom van Stiphout wrote:
>[color=green]
>>On 5 Apr 2005 12:53:45 -0700, jimfortune@compumarc.com wrote:
>>
>>I think it's VERY likely that MSComm uses those APIs under the hood.
>>There is no point in you rewriting it.
>>
>>-Tom.[/color]
>
>
> You are correct that MSComm very likely uses those APIs. The problem
> with the MSComm OCX, as I see it, is that certain software such as
> Visual Basic 6 or Visual Studio must be installed in order to supply a
> license required for its use. Since I have a legal copy of Visual
> Studio it only becomes an issue if others try to use the OCX version.
> It is still be useful for me to try the OCX first unless someone shares
> some API code. It would even save me time to see some sample MSComm
> code for this device although I've almost got that working now.[/color]

I believe a thread was on this NG about 3 yrs, or so, ago about just
using common file reading commands to read the COM ports. Here is a URL
of some dicussions about COM ports:

http://groups-beta.google.com/groups...=2005&safe=off

--
MGFoster:::mgf00 <at> earthlink <decimal-point> net
Oakland, CA (USA)

MGFoster wrote:
[color=blue]
> I believe a thread was on this NG about 3 yrs, or so, ago about just
> using common file reading commands to read the COM ports. Here is a[/color]
URL[color=blue]
> of some dicussions about COM ports:
>
>[/color]
http://groups-beta.google.com/groups...=2005&safe=off[color=blue]
>
> --
> MGFoster:::mgf00 <at> earthlink <decimal-point> net
> Oakland, CA (USA)[/color]

Thanks MGFoster. That link pointed me to

(Tony's site followed by 'serial' keyword for search)
http://www.granite.ab.ca/access/serialport.htm

which eventually pointed me to:

http://msdn.microsoft.com/library/de...sdn_serial.asp

The information at this URL is just what I need for the API route. I
think I'm going to skip the OCX route since I only need to be able to
read values. I.e., I don't need to implement all the functionality
that the OCX has.

James A. Fortune

jimfortune@compumarc.com wrote:

[color=blue]
>[/color]
http://msdn.microsoft.com/library/de...sdn_serial.asp[color=blue]
>
> The information at this URL is just what I need for the API route. I
> think I'm going to skip the OCX route since I only need to be able to
> read values. I.e., I don't need to implement all the functionality
> that the OCX has.
>
> James A. Fortune[/color]

This also helped:

http://msdn.microsoft.com/library/de...createfile.asp

James A. Fortune