[DXBase] Re: cw keying

Thu, 5 Dec 2002 19:44:46 -0500

Folks,
Thought I would share with you a support response that we received based on
a request we made regarding the CW interface.
Regards,
Courtney
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Our desktop, single user, application incorporates DriverX version 3.1 for
control of selected leads on the Windows OS serial/parallel port. These
leads are toggled as a high speed on/off switch. Most users report no
problem with the functionality in our application that pertains to DriverX;
however, we have two reports where the user advises that the driver files
are present in the appropriate Windows folders, that the registry entries
are present and valid, the address associated for each comport is correct
based on the user's hardware configuration. User further reports that the
driver has been verified to be active by reviewing there system menu of
devices/drivers. To the best of our knowledge, given all this, there should
be no reason for the functionality in our application not to work. Both
users who are currently having difficulty have something common. They have
both installed another third party application not associated with our
product. The third party product installed performs a function similar to
the one contained within our application and does manipulate the
serial/parallel port. In both cases, if the user activates this third party
application and then also activates our application, the feature in our
application that previously did not work, suddenly starts working. In other
words, our function calls to your driver are successfully executed and our
functionality performs as expected. If the user closes the third party
application, then the functionality in our application ceases to work. Can
you provide any insights that might explain this situation?
Thanks,
Jack
Scientific Solutions, Inc.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>12052002-001-ENG
Jack,
Interesting phenomena! A couple thoughts come to mind none of which can be
validated without detailed knowledge of both applications. But here goes:
1. The third party application you mention has installed a version of
DriverX that is registered on the user's system and prevents your
application from also registering the same DriverX. In this scenario, your
application would not be able to invoke DriverX because it is not registered
to your application; however, when the other application is running, calls
from your app to DriverX would succeed provided the version of DriverX
running and the version your code is written against have similar parameters
in the function calls being invoked. Since the very nature of the driver is
to shadow a comport, it is unlikely that there is a workaround since a
comport generally cannot have more than one driver shadow process active and
this is typically always active while the machine is booted up.
2. The third party application is not using DriverX. In this scenario, it
is likely that your installation of DriverX is properly registered and is
actually being loaded; however, the third party application has hooked the
address and/or interrupts associated with the comport it is using in such a
manner that unless it is running, other applications such as yours cannot
access the hardware.
3. What your users report in terms of the registry entries are not accurate
and they actually do not have DriverX configured properly in their registry
or the address associated with the comport is not correct. In this
scenario, the only way for your feature to work while the other application
is running would be by pure accident in as much as the other application is
intercepting your calls to DriverX and processing them on it's own. This is
a slightly different twist to number 2 above. Stranger things have
happened....Without knowledge of the third party application, we cannot
attach any weight as to how likely this scenario might be.
You are basically at the mercy of the end user to report accurate
information to diagnose anything further. Without being able to reproduce
this locally, your only option would seem to be accessing the users machine
remotely with root permissions and examine his system. I don't believe
anything in your report points to a problem with DriverX. If we can assist
further, let us know. If you wish to contract us to examine the user's
system remotely, to test their installation of DriverX, you can place your
support order via our support system. There is a minimum four hour support
charge for this service and actual billing will be based on time spent.
Billing begins at the time we begin configuration of our test machine in
preparation for access to the end user and billing stops at the time we
complete our examination. To accomplish this, user's must have PC Anywhere
for Windows installed and accessible via ISDN or DSL access. Users must
also disable any internet security software they may have running and must
configure their machine to allow remote port access. We no longer support
remote access via dialup.
Best Wishes,
Terry
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
----- Original Message -----
From: "Phil ON4VP" <[email protected]>
To: "FireBrick" <[email protected]>
Cc: <[email protected]>
Sent: Thursday, December 05, 2002 12:28 PM
Subject: [DXBase] Re: cw keying
bill, all,
I did all that and triple checked !!
Also the driverX is working under the 'non P&P drivers' in my device manager
!!
this is my reg edit extraction :
----- Original Message -----
From: "FireBrick" <[email protected]>
To: <[email protected]>; "DXBase List" <[email protected]>
Sent: Thursday, December 05, 2002 6:16 PM
Subject: cw keying
> Phil
> Open the Registry by using the Run feature in StartUp
> type regedit in the box.
> goto to Edit and select Find and enter DriverX
> Use F3 to find each instance.
> Eventually you should find DriverX with a submenu of Parameters
> There you should see listings called:
> Dxb98 COM1
> etc.
> Those are all of the comports that DXB utilizes and it's default
> I/O address.
> If that doesn't exist, then DXB was not installed correctly or Windows
> doesn't recognize the DriverX.
> Double check that the Portbase value for each comport agrees with the I/O
> address seen for that comport in the Systems, Hardware, Comport, Resources
> windows.
>> And just for the heck of it....I forgot which Win Version your using
> But copy DriverX.sys and .vxd to Windows/System and also
> Windows/System32/Drivers also.
> Having it in multiple places won't hurt and could help.
>>>>> -----------------------------------------------------
> Newspaper Headline: Clinton Wins Budget; More Lies Ahead
> -----------------------------------------------------
>> Bill H. in Chicagoland
>>>>
--- StripMime Report -- processed MIME parts ---
multipart/related
 multipart/alternative
 text/plain (text body -- kept)
 text/html
 image/jpeg
The reason this message is shown is because the post was in HTML
or had an attachment. Attachments are not allowed.
Please post in Plain-Text only.---
_______________________________________________
DXBase Reflector - Please visit us on the web at www.dxbase.com
- - - - - - - - - - - - - - - - - - - - - - -
To UNSUBSCRIBE please visit:
http://mailman.qth.net/mailman/listinfo/dxbase