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
