>More information about FoxPro 2.6 and Win2k problems.
>
>It seems that if you have a network printer set as your default printer and no network connection present that you
>
>can not use FoxPro 2.6 for development. If you try and modify a screen then it exists with no messages. When running
>
>an EXE if you try and preview a report FoxPro exits as well. If you restore the network connection or change the
>
>printer to a different printer all is well again. This is a summary of our findings:
>
>1) If your default windows printer is set to LPT1: and it is off / not present / present then FoxPro functions
>
>correctly.
>2) If your default windows printer is on a network and the printer is off and and you have a network connection
>
>FoxPro functions correctly.
>3) If your default windows printer is on a network and the network connection is not present (on your local PC)
>
>FoxPro fails to work.
>
>Situation 3 can easily be tested by doing the following:
>Set the windows default printer to a network printer.
>1. Load FoxPro 2.6
>2. Modify a form.
>3. Note that all is OK.
>4. Unplug network cable from PC. (Marvel at how well Win2k copes and gives you a nice message in a bubble over the
>
>system tray)
>5. Modify same form.
>6.
.
>7. Change default printer to a local printer.
>8. Load FoxPro 2.6 (because it crashed)
>9. Modify form.
>10. All OK.
>
>This situation is fairly unlikely - your network connection being lost while the system is in use. What is a more
>
>likly situation is that you have a laptop with a default windows printer set to an office network printer. You take
>
>the laptop away from the network - home / customer site etc and try to use FoxPro 2.6 and it crashes. No error
>
>messages or clue as to what it is doing. If you disable the network connection in Win2k the problem doesn't occur.
>
>You have to unplug the network cable from the PC.
>
>I sure hope this issue is addressed in a Win2k compatibility update...
This may seem callous, but I don't particularly care - I think you're trying to play poker with a pinochle deck to bitch and moan about a 'way out-of-date, discontinued, unsupported product with known problems running under an OS hat wasn't even a twinkle in it's daddy's eye when it came out. You'd have the same problems trying to write in some great-great-granddaddy of Visual Basic 6 under Win2K or XP. Take a hint - developing in a Win16 product in a network environment that has to deal with radical changes in OS architectures is a losing proposition. I've been dealing with such problems since I was a systems programmer on big IBM iron over 25 years ago - you think life is tough, try converting COBOL '68 apps to move from OS/VS2-SVS to OS/VS2-MVS with CICS some time. You either leave the freaking platform alone and live in the limits of the old platform, or you upgrade your tools and port/rewrite as necessary. That's life - adapt or go extinct.
Dealing with reality sucks at times. While you may have a problem, it's of your own making, and unfortunately, the people who might be able to help you stopped supporting the product several years ago. I don't consider the inability of Win2K to run what was even in it's prime a variant Win16 app that had known problems when the underlying hardware platform shifted in just a single specific configuration a major compatibility issue to be dealt with expeditiously by MS, any more than I'd expect them to drop everything and recode XP because my Tank video game that ran great on a 6MHz AT under DOS 2.0 won't run under XP Pro...
