The FoxTabs Challenge

 

The latest FoxRockX issue includes an article on FoxTabs by Rick Schummer. After months of neglect, that inspired me to get another release out, so you can now grab FoxTabs 0.9 beta from VFPX. My feeling is that FoxTabs is now “feature complete” for a 1.0 release, although I would not be surprised if there are a few more releases to shake out any remaining bugs. Please download the latest version and help us get to 1.0!

As Rick points out in the article, stability can be an issue, especially while testing your code in the ide. To that end, I added a pause button that removes all event bindings temporarily. If things get a little flaky during testing, or if you just don’t want to risk any interference from FoxTabs, press the pause button. When you’re done, press resume and you’re back in business.

Wikipedia says the following about observation:

One problem encountered throughout scientific fields is that the observation may affect the process being observed, resulting in a different outcome than if the process was unobserved.

Unfortunately, that can sometimes be the case with FoxTabs, making stability the number one challenge of this project. We have come a long way since the initial release of FoxTabs, but there is more work to do. Capturing and responding to the myriads of events flying around can sometimes cause unpredictable results.

This is compounded by the fact that the various VFP IDE windows are not exactly consistent in their behavior. For example, most IDE windows broadcast a WM_SETFOCUS message when activated, which FoxTabs uses to highlight the associated tab. But the Project Manager doesn’t send out a WM_SETFOCUS. Why not? I don’t know. Neither does the Properties window, but it’s different than the Project Manager, because each of its tabs sends out its own messages. I had to find the right combination of events and messages, so that FoxTabs responds consistently to all IDE windows. This can be frustrating, but it’s also interesting, because you get a tiny peek at what’s going on under the hood.

Of a more serious nature is when some amalgamation of events combined with FoxTabs produces unexpected results, or worse, a C5 crash. That’s when you get the sinking feeling that your productivity tool has just become an un-productivity tool. These can be difficult to track down.

A few months ago a developer reported crashes when opening the debugger. I was able to open the debugger without issue using set step on or a breakpoint. It took me a whole day, but I eventually traced this to the Call Stack window, which only caused a crash if you opened it after suspending a program. It was a very specific set of circumstances that led to the crash. Fortunately, I was able to find a workaround.

Another interesting case was fixed in the latest version. Opening the expression builder
using GetExpr() worked fine. However, if you opened it from the functions and expressions button in the view designer, boom! Fox crashed. I traced the problem to this code from the FoxTabs window event handler:

function wmeventhandler(hwnd as integer, msg as integer, wparam as integer, lparam as integer)

local oexception as exception
local lnreturn as integer
lnreturn = 0
***
black hole: hwnd and msg do not exist ***
…
* must pass the message on
lnreturn = callwindowproc(this.prevwndfunc, hwnd, msg, wparam, lparam)
return lnreturn

endfunc

Windows events pass four parameters to the event handler: hwnd, msg, wparam, and lparam. When opening the expression builder from the view designer, those variables don’t exist in the event handler. I don’t mean that they are not assigned a value, I mean that they do not exist! How is that possible given that the variables are clearly defined as parameters only a few lines earlier? It’s as if they were sucked into a black hole and out of existence. When you try to access the variables or pass the event on to its original destination (CallWindowProc), Fox crashes because nothing is there. It’s one of the strangest things I’ve seen in Fox. I was able to plug the hole by checking if the variables exist and simply returning if they do not. My hope is that this is the same hole causing other random C5 errors, and that those are now fixed.

So, yeah, there are some challenges, especially when you’re not a C/C++ programmer and you don’t deal with this kind of stuff every day. But I do have to say it is very satisfying to find solutions to these problems, and I learn a lot in the process. I guess this isn’t the best sales pitch
for using FoxTabs, but I think we’ll get there. I hope you give it a try and let us know how it works for you.