Prev: Problem with a Registry program from Karen Kenworthy
Next: How to incorporate voice commands into a VB6 application on XP?
From: Frisbee� on 10 Apr 2010 16:40 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 10 Apr 2010 16:46 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 11 Apr 2010 00:18 "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 11 Apr 2010 00:40 "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 11 Apr 2010 02:36
"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 |