From: Frisbee� on
Nobody wrote:
> "Nobody" <nobody(a)> wrote in message
> news:OuglZ4S2KHA.5680(a)TK2MSFTNGP02.phx.gbl...
>> "Frisbee�" <discgolfdad(a)> wrote in message
>> news:uBA8e7O2KHA.5588(a)TK2MSFTNGP06.phx.gbl...
>>> Is there something about loading controls via Terminal Services that
>>> could cause a problem that you're aware of?
>> No. The only issues with Terminal Services that I am aware of are
>> multi-user issues, such as opening files exclusively in a local
>> computer, which would not work, or trying to use the same hardware
>> resource, such as COM1, etc.
>> You can test your app with Terminal Services if you have XP or
>> after. Just create another user account, and log in. You can switch
>> between sessions using the welcome screen or using Start-->Log
>> off-->Switch User. Note that some network adapters replace GINA and
>> this disables the welcome screen. Search MSKB for "GINA welcome
>> screen" in how to restore it. The welcome screen is also disabled if
>> the computer was configured to log in to a domain. This is also
>> explained in MSKB.
> Also, if you are saving options to a per computer location, then one
> user could overwrite another user settings. If you are using a per
> user location or HKEY_CURRENT_USER, then it's not a problem. Each
> logged on user has its own copy of HKEY_CURRENT_USER.

I am using the GetSetting and SaveSetting functions, which I am pretty sure
use the hkey_current_user settings.

The main form does open files (login ID's, security, etc.) but not in
exclusive mode. I also do not access hardware directly. I do check the
printers collection.

You've given me a lot more questions to ask the client, at least. Thanks.

From: Frisbee� on
Tinker wrote:
> "Frisbee�" <discgolfdad(a)> wrote in message
> news:uBA8e7O2KHA.5588(a)TK2MSFTNGP06.phx.gbl...
>> Nobody wrote:
>>> "Frisbee�" <discgolfdad(a)> wrote in message
>>> news:uMOI5oN2KHA.1016(a)TK2MSFTNGP02.phx.gbl...
>>>> Boris Pauljev wrote:
>>>>> What kind of a control are you using in the left side of the app?
>>>>> Looks like something from vbAccelerator, judging from the
>>>>> screenshot on your website.
>>>>> This would be my first guess for an source of error.
>>>> Nice catch. It isn't vaAccelerator, but it is Infragistics Outlook
>>>> Bar and Explorer controls.
>>>> Problem is, I have not altered -anything- on that main form for at
>>>> least a year, and the program -was- running just fine up until a
>>>> couple of week ago. I did suspect it was a form_resize event, since
>>>> I do indeed alter the size of the outlook bar, explorer, and two
>>>> command buttons based on previous settings stored in the registry,
>>>> but the resize event is apparently not fired until the form is
>>>> shown, and it never even enters the form_load event on that
>>>> machine.
>>> Controls are loaded between Form_Initialize and Form_Load.
>> I did not know that, but it makes sense.
>> In addition to the Infragistics ActiveX controls, it also loads an
>> 8.5 instance of Crystal Reports, several Pervasive (Btrieve) ActiveX
>> controls, and probably a dialog control.
>> Is there something about loading controls via Terminal Services that
>> could cause a problem that you're aware of? Keeping in mind that I
>> have not updated any of the controls in a very long time, either,
>> meaning neither form nor controls should have changed in any way
>> between the versions that worked and the subsequent versions that do
>> not. For what it's worth, I even tried switching between native code and
>> p-code, and several of the various native code compile options - no
>> combination seemed to make a difference (but I was surprised that the
>> p-code exe was 33% smaller than the native code).
>> I'm thinking I probably need to look at his installation logs (I use
>> Inno Setup) and see if perhaps he's getting some kind of error
>> during the install. The guy is pretty sharp - a power user (at
>> least compared to most of my customers) so I can't believe he's
>> ignoring an error message during install, but you never know.
>> Thanks for the pointers.
> I would be tempted to check for an updated file on one of the
> controls you are using.
> We had similar problems ultimately tracked down to an OCX that was
> newer on the client machine than my development machine. I think in
> this particular case, said OCX had been updated as part of installing
> a printer. Of course these OCX files are supposed to be backwards
> compatible, but they aren't always....

I can understand the logic behind that, and I may have him check versions
anyway, but I doubt that could be the problem, since re-installing an older
version of my own app seems to solve the problem AND the fact that after
installing a newer version of my app, he CAN run it locally, but the failure
happens when running from the remote terminal. How could an ActiveX control
run correctly on the local machine, but not on a remote via terminal
services? If I understand TS correctly, it acts as nothing more than
something like CrossLoop or even RDP in that it runs 100% on the local
server, and just transmits screens and input back and forth literally like
the old time "dumb" terminals did, so if it runs on the local machine, why
would it not run remotely, and why would one version of the executable work
on both machines, and another only on the local? I've not updated any ocx
or dll files in a long time, certainly not since the version that stopped

Thanks for your input.