“So, Where Ya Been?”

Over the past year or so, I’ve received a couple of emails from folks asking why my blog had disappeared.

Last week, I found a post on Foxite asking “What happened to Kevin Ragsdale?”

My response (edited for this post) was:

I’m still alive, just been a bit less visible over the last couple of years due to personal and professional reasons.

Professionally, I was bored. Bored with my (non-FoxPro, all ASP.NET/VB6/SQL Server) job and uninspired to do anything. I spoke at the Advisor conference in early 2007 and was very disappointed in my preparation and delivery of the sessions (and non-delivery of session materials). Then I spoke at FoxForward in September and was, once again, disappointed in my preparation.

All of this built up and I felt I just didn’t have anything interesting to say anymore.

On the personal side I would have left my stuff online, but I deleted most everything based on my attorney’s advice, during a child support and custody battle.

It looked like the court would side with me, until my ex’s attorney showed up with copies of all of my blog postings, screenshots of my websites, pictures of me speaking at conferences (and enjoying more than a beer, or two, or ten), etc.

My attorney — worthless piece of garbage that he was — folded like frightened child he saw this presentation of my “success.”

According to them, I was a highly successful, world-famous (thanks to the Desktop Alerts) software developer who had taken a lesser job solely to reduce my child support payments.

Of course, I knew I was barely scratching by on the only job I could find in a five-month job search, but according to them I was simply the worst of all deadbeat dads.

Sometimes, an online profile just doesn’t work out.

In 2008, after attending a “town hall” meeting with my congressman, I decided to launch an independent run for Congress. For a few months, all of my energy (except the 40-hours per week at the job) was directed at that — didn’t work out too well, though — I finished 4th out of 4 candidates, behind a guy that said ‘selective breeding is the solution to the health care crisis in America.’

If I ever feel I’ve got something interesting to say, I’ll start blogging again. I have a new job, this time all FoxPro, which has completely rejuvenated me!

So, it all boiled down to some really bad advice and an irrational response to an impossible situation…

Flattered that anyone showed any interest in my thoughts, I spent most of the day Saturday combing through the Wayback Machine and a couple of old external hard drives, picking out as many of the old blog posts I could find, and ended up recreating 74 of the old posts.

As it turns out, “deleting” your “stuff” on the internet can be pretty doggone difficult, thanks to search engine caching and archives.

In the process of searching, I found that an old blog post of mine was used as a reference for a patent Microsoft was granted in August of last year.

Freaky!

Anyway, I’m now working full-time again with Visual FoxPro, and I’m looking forward to sharing my new development experiences with you.

Visual FoxPro ROCKS!!!

My HEROES happen {in Mesa, this October}

Went to the HEROES happen {here} (Visual Studio 2008 Launch Event) in Nashville today.

Overall, the event was pretty good (I attended the Developer Track) but to be honest, Icouldn’t wait to get home and check the Southwest Fox 2008 web site.

Today was “announcement” day: they announced the speakers and sessions, and openedregistration.

Speaker list (in alphabetical order):

Looks like MY Heroes happen {in Mesa}…

Had a chance to chat with Alan Stevens for a few minutes today at the launch event.  We both talked about how much we’ll miss FoxForward this year.  Kevin Cully and his family did a great job with the FoxForward conference the last two years.

Start saving your nickels and dimes!

This post originally appeared on Blogger.

Flicker-Free Web Pages (no javascript required)

I’ve spent the last few weeks playing with ASP.NET 2.0, and I’ve enjoyed using the AutoPostBack feature of the various server controls.

But one thing that drives me nuts is flickering web pages from the aforementioned AutoPostBack-enabled server controls, especially in the “Web 2.0 – Everything Is AJAX And If It’s Not It’s Just Crap” times we live in.

So, I started thinking more and more about AJAX, specifically the ASP.NET AJAX extensions. I started reading articles, help files, and book chapters but, doggone it, I just didn’t get the concept.

Then I watched a video on the ASP.NET web site that gave me the “a-ha!” moment I needed.

Basically, you just do the following:

  • Add a ScriptManager control to the page
  • Add an UpdatePanel control (for the piece of the page you want to update
  • Set the <ContentTemplate> tag of the UpdatePanel (this is the HTML you want displayed in the UpdatePanel part of the page)
  • Set the <Trigger> tag of the UpdatePanel, telling it which control and event on the page that should “fire” the update

I put together a small web site to demonstrate the results of the “a-ha!” moment, and also put together a screencast to show anyone that hasn’t yet had the “a-ha!” moment how easy it is to add partial page update functionality to an existing web page.  Be sure to click the “full-screen” button for best results.

Please, before I start getting comments about how elementary my code and examples are, let me say this: “I am a Visual FoxPro developer, not a .NET developer, and I’m learning this stuff day-by-day.”

And here’s a link for the code.

Side note: the downloads are hosted in a public folder I set up on Skydrive. No bandwidth charges, and no hosting charges! Just a thought for folks who might have something cool to share but do not want to pay out the wazoo if it becomes popular.

Enjoy!


This post originally appeared on Blogger.

DLL Hell Rears Its Ugly Head

If there’s a moral to this story, it’s this: Watch Your Runtimes.

Oh, yeah, and this: Trust No One.

A little background:

Last year, I had an opportunity to develop a shrink-wrap application using Visual FoxPro 9.

The product was originally released in March of 2007, built with Visual FoxPro 9 Service Pack 1.

A couple of months ago, we released a major version update.

The new version was built with Service Pack 2.

Now, before the “I-Won’t-Install-Service Pack 2-Because-I-Heard-It-Has-Some-Bugs-And-Besides-I’m-Mad-At-Microsoft-For-Killing-FoxPro” crowd starts drooling at the prospect of this being a ‘Service Pack 2 Killed My App’ post, let me say this:

“Install VFP 9 Service Pack 2. Today. Stop reading this, and go try it out. Try it on a test machine. Try it on Virtual PC. Just try it! Quit whining about what it might do to your apps, and go see for yourself. You’ll never know until you try.”

Whew! That felt good to get that off my chest. Now, back to the story:

Everything was going great, until I received the following support email:

I’m getting a Visual Fox Pro error in shared file.
The error log is not telling me anything else.
Microsoft Visual FoxPro
Fatal error: Exception code=C0000005 @ 03/27/08 05:16:37 PM.
Error log file: C:Program FilesCommon FilesMicrosoft SharedVFPvfp9rerr.log
Does this mean anything to you?

A C0000005 error? Rut-roh…

I exchanged several emails with the user, trying to determine when, where, why, and how this was happening.

During the course of the email exchanges, the user sent me some screenshots.

She stated that the “first” error occurs immediately after clicking the application icon on the Windows desktop:

UhOh

If she clicked the “What data does this error report contain?” link, she got the following:

ErrorRpt

Well, that tells me alot. 😉

She clicked close on the window above, then clicked Don’t Send on the previous window, then boom:

C00005

While researching the issue, another user sent me almost the exact same email. He was very upset about the error, because it seemed to him that this thing called Microsoft Visual FoxPro was obviously some kind of spyware/malware/virus or something. After all, why else would the error report contain all these weird-looking code-thingies like ModName, ModVer, ModStamp, fDebug and Offset? After Googling “Visual FoxPro”, he went onto an MSDN Forum to ask why this was happening.

In-house, we tried and tried and tried to recreate the issue. No go. We couldn’t recreate the error no matter how hard we tried.

The next day, the first user sent me another email:

I’ve figured it out!!!!

Your updated program is fighting with another Visual Fox Pro program on my machine:

I discovered this when I opened the program and received the same error.

Both programs are very important to me and I’ve also been in touch with them, too. I’m hoping we can get all the programmers heads together to figure out how to resolve the problem.

Can you tell me which VFP version you are using for your program so I can report back?

I asked her for the name of the “other” program, and I went to their website and downloaded a 30-day trial version of their software. I fired up Virtual PC and installed the program. Imagine my surprise when I saw the Wise Installer putting VFP9R.DLL in the C:WINDOWSSYSTEM32 folder.

While you’re at it, also imagine my expletive-filled shouts while watching the install.

RunTime

These runtime files, from that “other” program, were Visual FoxPro 9 Service Pack 1 runtimes.

I then installed my app, which put the runtimes in the following folder:

VFP9SP2

Started up my app, and BOOM!!! The issue has now been “officially” recreated.

I contacted the makers of the other software, and pointed them to the FoxWiki pages about VFP Runtimes.

But, not wanting my app to be at the mercy of another development shop, I changed my installer to just dump the VFP 9 SP2 runtimes into the folder where the app is installed.

Fixed

No registration, no nothing. Just a file copy.

I restarted my app, and it worked! Woo Hoo!!!

I sent the new installer out to the affected users, and they reported back that the “new version” worked. I loved the “new version” part, because the only thing that changed was the install itself.

Of course, the “other” app was still broken, because when my app was originally installed the new VFP runtimes were registered on the system.

A quick reinstall of the “other” app caused the VFP 9 SP1 runtimes to be re-registered in C:WINDOWSSYSTEM32, and now both programs “work” and my users are happy once again.

From now on, all of my apps will have the VFP Runtimes placed in the same folder as the app itself.

Watch Your Runtimes.

Trust No One.

This post originally appeared on Blogger.