I think it was Jim Booth who used to say this in his sessions. It's a valuable lesson one shouldn't forget. Given that frmDialog.SCX is a form with just one label and the following code in the Init:
Thisform.lblMsg.Caption = m.tcText
Do you see any problem with the following code?
DO FORM frmDialog.SCX WITH "Deleting customer."
DELETE NEXT 1
Well, I didn't at first glance when I reviewed the code. However, displaying a form makes an awful lot of events happen, like the Activate event. Obviously (after thinking about it, of course), any of these events can change the current work area and not properly reset it. DELETE doesn't necessarily delete the customer record; it can be any record in any table. In fact, destructive commands like DELETE, ZAP or even REPLACE should never be used without the IN clause.
Grids, images and a crash.
In my session "Crashing VFP and preventing crashes" I show that displaying a corrupted image in a grid crashes Visual FoxPro. There's actually more to that as such a crash isn't limited to invalid images.
Right now I'm working on a control that displays images as small thumbnails. Take a look at the Windows Vista Photo Gallery to get an impression what the control looks like. There have been a few lessons I learned from writing this control.
Using BackStyle_Access is a cool technology. Unfortunately, cool does not always translate very well to fast. It might be related to the fact that I display several images in each grid cell. However, BackStyle_Access is called several times for each cell. The strangest thing happens when the form with the grid does not have the focus. In this case, the access method fires permanently. Moving around in the grid is sluggish at best. Again the grid redisplays all images every time the column or row changes.
Hence, I switched back to the traditional DynamicCurrentControl approach having one container for every row. Displaying images works much faster now. Unfortunately, crashing Visual FoxPro is easy, too.
The grid control is very sensitive to displaying itself while it has focus. That's a known issue. For instance, when I need to call the Refresh method, I usually move the focus to some non-visible control, call Refresh and then move the focus back. Not doing so can cause the grid to show no records. They would only come back if you click on the grid and press the up arrow key.
It's not only Refresh that is making problems, but drawing operations in general. In my image control I use the MouseWheel event to resize the image. Doing so changes RowHeight, the width of the column, potentially the ColumnCount property and also needs to redraw all images in the grid. Sooner or later the form crashes. So far, the one rule seems to be that the grid crashes the faster the more optimized my code is. I guess it's related to the number of drawing operations or maybe some overlapping actions.
Funnily - well, not - the crashes only happen when the grid is starting the series of events. Using the mouse wheel on the grid, moving around in the grid very quickly, both crash VFP. But if I trigger the same action from a command button outside the grid, so far I haven't got a crash.