float inexact result
in [Visual Basic]
|
Prev: Registration for vbAdvanced
Next: Simple Obfuscation
From: Nobody on 14 Mar 2010 23:15 "mayayana" <mayayana(a)nospam.invalid> wrote in message news:O565Zb6wKHA.3564(a)TK2MSFTNGP05.phx.gbl... > >> >> One possible reason is binary compatibility. > > It's a plain EXE, not an ActiveX EXE. I meant components that you are using. Also, do you do any subclassing in this program? If so, try disabling it and see if the error goes away.
From: mayayana on 15 Mar 2010 01:51 > >> One possible reason is binary compatibility. > > > > It's a plain EXE, not an ActiveX EXE. > > I meant components that you are using. > No components. No dependencies. > Also, do you do any subclassing in this program? If so, try disabling it and > see if the error goes away. > I am using a number of self-subclassing buttons based on userControls, but it's something I've used before. I could try taking those out if I don't find another answer, but it wouldn't be easy. And this doesn't seem like a subclassing bug, since it's not hapening in the IDE and only happens in the compiled program after it's quit. I found one discussion online where someone suggested that a call to an outside DLL might be at fault -- something that the EXE is unloading but that doesn't get unloaded in the IDE. But again, I haven't added anything like that and the code used to work fine. Stranger still, I seem to have got it fixed now in Win98. I'm testing on 98/XP/7. Trouble is, I don't know how I fixed it on 98. I tried waiting longer to release a class in use, but I can't actually find a reason why that would affect anything. And that "fix" doesn't work on XP/7.
From: mayayana on 15 Mar 2010 14:24 I figured this out, though it still doesn't seem to make sense. I'm using custom buttons that involve an Image control on a userControl. Self- subclassing with Paul Caton's code. Also using TrackMouseEvent to get hover. I've done this quite a bit with no problems. It turns out that the crash happens when two things are true: * The program close sub is called from a custom button click event. * The close sub ends with "End". I never ran into this before because I've never used a custom button to close the program. I've closed from the Control Box and it works fine. Even if I unsubclass the exit button in its own click event, before calling the program close sub, it still crashes. I know that "End" is not recommended. I like to use it for insurance, the logic being that if I've really cleaned up then End is OK. In tests I can tell that all buttons have ubsubclassed before quitting, and the program seems to be fully unloaded without End, but I still don't understand why this should be a problem. I'm fine with not using End, but I'd like to be certain I'm not leaving something in memory. In some scenarios I've stopped the problem in Win98, though I'm not exactly sure how. Is it possible that VB just needs a little extra time for something, despite having fully unloaded, and that I'm cutting it short by using End? > >> One possible reason is binary compatibility. > > > > It's a plain EXE, not an ActiveX EXE. > > I meant components that you are using. > > Also, do you do any subclassing in this program? If so, try disabling it and > see if the error goes away. > >
From: dpb on 15 Mar 2010 16:14 mayayana wrote: > I figured this out, though it still doesn't > seem to make sense. .... > > * The program close sub is called from a > custom button click event. > > * The close sub ends with "End". .... > I know that "End" is not recommended. I like > to use it for insurance, the logic being that if > I've really cleaned up then End is OK. Bad idea... .... > In some scenarios I've stopped the problem in > Win98, though I'm not exactly sure how. Is it > possible that VB just needs a little extra time > for something, despite having fully unloaded, > and that I'm cutting it short by using End? .... Something like that I'd say is quite likely. End is "NOW!"; anything scheduled but not executed yet is possibly cannon fodder, I'd think it possible all sorts of race conditions and outright failures could arise under various scenarios w/ differing OS levels/patches/etc... --
From: mayayana on 15 Mar 2010 17:55
> End is "NOW!"; anything scheduled but not > executed yet is possibly > cannon fodder, I like that metaphor. :) Everything seems to be getting cleaned up OK without End so I guess I'll just leave it out and assume that the button clicked has some lag in being able to unload. Thanks. |