From: Frisbee� on
Helmut Meukel wrote:
> "Frisbee�" <discgolfdad(a)gEEmail.com> schrieb im Newsbeitrag
> news:uMOI5oN2KHA.1016(a)TK2MSFTNGP02.phx.gbl...
>>
>> 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.
>
> This is just a wild guess triggered by MS Photo Editor (known to store
> erroneous values for its windows position in the registry and next
> run its window is out of sight):
> Has your program already retrieved those values from the registry?
> Are they in the expected range? Maybe they cause the crash.
> Does your program check those values or just pass them to the
> controls?
> Helmut.

That was my very first suspicion. There was a time when I would store the
windows position settings without checking windowstate, and subsequently if
a user closed the application with one or more windows minimized, it would
later attempt to restore the window as minimized but fail because it was
also trying to set position. Likewise, a user can go "hog-wild" when trying
to resize the outlook bar and explorer panes, but I've since set minimum and
maximum values for those as well. Getting the settings is the first thing
that the app does in the form_load event, but my debugging code would be
displaying a message that it at least got that far in the debug mode, and
it's not.


From: Frisbee� on
Nobody wrote:
> "Frisbee�" <discgolfdad(a)gEEmail.com> 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.


From: Nobody on
"Frisbee�" <discgolfdad(a)gEEmail.com> 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.

Good luck!


From: Nobody on
"Nobody" <nobody(a)nobody.com> wrote in message
news:OuglZ4S2KHA.5680(a)TK2MSFTNGP02.phx.gbl...
> "Frisbee�" <discgolfdad(a)gEEmail.com> 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.


From: Tinker on

"Frisbee�" <discgolfdad(a)gEEmail.com> wrote in message
news:uBA8e7O2KHA.5588(a)TK2MSFTNGP06.phx.gbl...
> Nobody wrote:
>> "Frisbee�" <discgolfdad(a)gEEmail.com> 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....

Tinker