Hugo

So here is now a real-life example of a bug in WinDev, imo. This morning our program hit a problem; code that had been working now fails. No changes to hardware, software, or WinDev. So must be something new happening. Analysis shows the following:

1) I have a filter set on a table: HFilter() in WD vs. SET FILTER in VFP

2) I do a search for a non-existent record: HReadSeekFirst() in WD vs. SEEK() in VFP

3) Boom - GPF! - General Protection Fault in a WD DLL. What the … ??

On investigation I find that this has not occurred before in our app i.e. records normally always exist in this routine. Further investigation shows that if we remove the filter then all works fine and as expected i.e. the seek returns False. So we assume this is a bug in WinDev, yes?

I read up the help on HReadSeekFirst() and there is an additional optional parameter possible called HKeepFilter. Using this additional option prevents the GPF even whilst keeping the filter in operation.

So is this a WinDev fault or not? I think it is because the program should not GPF. An error maybe but not a GPF. Preferably no error either but just return false for the seek. Anyway, it does do GPF.

So using WinDev IDE we open a support ticket directly to PC Soft. This is an automated process largely, answer a few questions, provide description of problem, preferably provide reproduction code and, if at all possible, a small test project to show the issue occurring. I did everything except making the test project (too lazy for that right now). The support ticket was sent to PC Soft at 8am UK time. A ticket number is generated and returned.

What will happen now? I will get an answer in 24 to 48 hours, I am sure. In my opinion they will tell me to use the HKeepFIlter option in the HReadSeekFirst() function since that does solve the problem and avoid the GPF. I think they will NOT release a new DLL fix in the current version for me but might provide this fix in the next version due next year +/-April.

Will let you know their reply :)