|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
APP behaves differently in IDE vs EXEbeen running fine for a while but I started to see a problem on machines running XP with SP2. The user enters values into cells in a row. When they move off the row, the new values are saved to the database. It all works fine except on XP/SP2. The new values are saved correctly to the database but the old values are redisplayed in the old row as focus moves to the next row. I recently installed SP2 on my XP development machine to try to figure out what was going on and I ran across something strange. On my machine running XP/SP2, if I run the application from within the VB6 IDE it runs fine. I don't see the display problem in the grid. On the same machine, if I compile the application and run the exe, I see the display problem. I'm not sure what this means. It's obviously going to be processing something differently from the IDE compared to a compiled EXE but I don't know exactly what. I would assume if the app is running on the same machine it would using the same libraries and dells regardless of whether it is running from the IDE or from a compiled EXE. Anyone have any ideas about what is going on here? Thanks! Terry "Terry Diederich" <terry@terrynospamdiederich.com>'s wild thoughts were released on Tue, 24 May 2005 08:17:20 -0500bearing the following fruit: Show quoteHide quote >I have a VB6 app that is using DBGrid32.ocx as an unbound grid. The app has Hard to comment on your precise problem but yes it does>been running fine for a while but I started to see a problem on machines >running XP with SP2. The user enters values into cells in a row. When they >move off the row, the new values are saved to the database. It all works >fine except on XP/SP2. The new values are saved correctly to the database >but the old values are redisplayed in the old row as focus moves to the next >row. > >I recently installed SP2 on my XP development machine to try to figure out >what was going on and I ran across something strange. On my machine running >XP/SP2, if I run the application from within the VB6 IDE it runs fine. I >don't see the display problem in the grid. On the same machine, if I >compile the application and run the exe, I see the display problem. > >I'm not sure what this means. It's obviously going to be processing >something differently from the IDE compared to a compiled EXE but I don't >know exactly what. I would assume if the app is running on the same machine >it would using the same libraries and dells regardless of whether it is >running from the IDE or from a compiled EXE. Anyone have any ideas about >what is going on here? > behave differently in the IDE and compiled app. Timing is different for one thing and that fraction of extra time it takes to do something in the IDE over a compiled app can indeed cause it to behave differently, perhaps a refresh doesn't happen or an even doesn't fire. Jan Hyde (VB MVP) -- Did you hear about the guy who blamed arithmetic for his divorce? His wife put two and two together. (Art. Moger) [Abolish the TV Licence - http://www.tvlicensing.biz/] > Timing is different for one thing and that fraction of extra I was hoping that I'd be able to step through the app in the debugger to > time it takes to do something in the IDE over a compiled app > can indeed cause it to behave differently, perhaps a refresh > doesn't happen or an even doesn't fire. pinpoint the spot where previous values in the grid are restored so I was disappointed and somewhat surprised when everything worked correctly. I guess I'll have to try writing debug lines to a log file, although I suspect that could possibly effect timing also. Strange, I've never run into this before. "Terry Diederich" <terry@terrynospamdiederich.com>'s wild thoughts were released on Tue, 24 May 2005 09:27:34 -0500bearing the following fruit: >> Timing is different for one thing and that fraction of extra It could but thats the techneque I use and it's worked for>> time it takes to do something in the IDE over a compiled app >> can indeed cause it to behave differently, perhaps a refresh >> doesn't happen or an even doesn't fire. > >I was hoping that I'd be able to step through the app in the debugger to >pinpoint the spot where previous values in the grid are restored so I was >disappointed and somewhat surprised when everything worked correctly. I >guess I'll have to try writing debug lines to a log file, although I suspect >that could possibly effect timing also. me so far. >Strange, I've never run into this LOL, you must be lucky, we've hit it dozens of times each.>before. Jan Hyde (VB MVP) -- Q. What's large, gray and doesn't apply? A. An irrelephant. [Abolish the TV Licence - http://www.tvlicensing.biz/] You can try using the VC debugger, if you have it. In the VB project
settings, select the option "Create symbolic debug information", then create an EXE. In the VC debugger, select "Open Workspace", select the EXE of your app, and manually open any (VB) source files you need. Then you can set breakpoint. There are some severe limitations, e.g. you cannot view all variable values, but you can see which path the program takes, and view some variable values. Robert Show quoteHide quote "Terry Diederich" <terry@terrynospamdiederich.com> wrote in message news:uMXNBzGYFHA.3572@TK2MSFTNGP12.phx.gbl... > > Timing is different for one thing and that fraction of extra > > time it takes to do something in the IDE over a compiled app > > can indeed cause it to behave differently, perhaps a refresh > > doesn't happen or an even doesn't fire. > > I was hoping that I'd be able to step through the app in the debugger to > pinpoint the spot where previous values in the grid are restored so I was > disappointed and somewhat surprised when everything worked correctly. I > guess I'll have to try writing debug lines to a log file, although I suspect > that could possibly effect timing also. Strange, I've never run into this > before. > > > You can try using the VC debugger, I didn't know you could do that. I'll give it a try. Thanks Robert!In case anyone is interested I found a workaround to my problem. I don't
know what is causing the problem exactly but I can get the app to work consistently now at least. The app is using the dbgrid32 control as an unbound grid. According to the help file, setting the bookmark property to itself will force the current row to be updated through the UnboundWriteData event. I did this in the grid's AfterColEdit event and the display problem went away. I am not sure what changed with XP/SP2 that now requires this but it took care of the problem. The display worked fine in W98 and XP/SP1 without this line. However, there seems to be a side-effect of this change that I now need to deal with. Since I've added the line to set the bookmark property to itself, the grid is acting slightly differently. Whenever I edit a column and then move to a lower row, the grid scrolls everything so the row I just edited is now the top visible row in the grid. This now happens only on XP/SP2. I have the same EXE running on a machine with XP/SP1 and the grid does not automatically scroll the rows as you edit them. This is only happening with XP/SP2 and has only started to happen since I added the line to set the bookmark to itself. If I remove the line to set the bookmark, the scrolling issue goes away. I'm just starting to look into this. If anyone has any suggestions for the scrolling issue, I'd appreciate hearing them. Thanks Terry |
|||||||||||||||||||||||