Bug: Win2000 and Dialog Screens

[Brak]

Hello,

I discovered a problem with FPW distributions running on Win2000.

For some reason you CAN NOT click on the list boxes.

For example say you invoke the GETFILE() command. When the box comes up you can not select the folder, nor the file.

In the development environment (running as an APP or PRG) it acts normally, but as an EXE it is buggy.

This is the second issue in which I found problem with code acting differently when compiled.

Anyone with any insight on this?

Could some of your create a quick exe which calls the GETFILE() function and confirm that the bug occurs.

On Win9x it works just dandy. Win2000 it bugs out.

Thanks in advance.

B"H
Brak

 

[cricket]

see thread 182-1036574 or do a search on GETFILE()

 

[Brak]

I checked the thread you suggested and it had nothing to do with the problem I am describing. Also the GETFILE() search turned up nothing.

The problem isn't just with the GETFILE() function, but any dialog screen which has list boxes. I mentioned the GETFILE() because it is a fox-created screen - not one that I created which could have other issues contributing to the problem, and also because it is an easy way for otherson this forum to check and confirm as you can just make an PRG whcih calls the GETFILE() command and turn it into an EXE - as opposed to asking people to go through the chore of creating a screen and such.

The problem I'm reporting is that you can not click on list boxes when running an EXE as opposed to an APP/PRG.

Nothing crashes, and you can still use keyboard navigation to select the list box and the item you want - but the mouse doesn't work with them.

B"H
brak

 

[Scott24x7]

Bark,
Just a quesiton... is there any code in the WHEN clause???

If so, can you post it?



Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[Brak]

The problem has nothing to do with an other coding. If you just make a PRG which has nothing but

=getfile()

and compile that as an exe you will get the problem.


I notice an other level of goffiness.
To test this goofiness all you need to do is make a project with a screen. Make a button and have the button trigger the =GETFILE function and of course an exit button.

Now run the exe. CLock on the button and you will get the file dialog acting weird as reported. Now, while it is running start Foxpro and click on File and Open. Then just click cancel.
Now go back to the exe and click on the button and you will get the same file dialog screen but now it works. YOu can quit foxpro, and it will continue to work. But if you quit your program and start it again the problem returns!

So it seems that some functionality that is in the fpw26.exe and should be in the ESL is missing.

The question will MS doing anything to fix this problem - like they did with the fast machine problem.

Can someone try this to confirm that its not just happening to me.

Thanks in advance.

 

[Scott24x7]

Bark,

The problem I'm reporting is that you can not click on list boxes when running an EXE as opposed to an APP/PRG.

I see the problem... It was that statement above that caused me to ask the WHEN question...

It is very peculiar... I have WinXP running on everything at the moment, so can't replicate it without Win2000, and seems fine in XP. Am wondering if you have some other peculiarity in either your application design, or the machine... This seems too odd to not have been reported before.

As for support for a fix from Microsoft, on this one, I'd say no way... 2.6 has been out of production for so long, I don't believe they have anyone focused on any development around supporting it any longer, and have not had for quite a while. If it's broke, in Win2000 I'd say your best solution is to use a non-Win2000 OS, ether going backward ('98) or forward (XP).

Wish I had a better answer for you.


Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[Brak]

Thank you for confirming my problem.

The problem is with the EXE/ESL - which is intended for distribution to other computers who choise of OS isn't mine to say. So I need the program to work right under Win2K since some of the users might be running that OS and if I tell them they can't run it under Win2K then they most likely won't use my program unless for some reason they feel extremly compelled to use my program.

So since it seems to be an OS problem, and since MS is still supporting Win2K - how do i go about reporting this to MS so they can make a patch to either fix Win2K or FP?

How did the people who successfully reported the "fast machine" bug get the issue fixed?

 

[Scott24x7]

Brak,
You can go to

http://www.microsoft.com

don't know where specifically there, but there will be a place for you to send questions to Microsoft. I assume you can submit "bug reports" there too. It will be up to MS to determin if it is a W2K issue or a FP2.6 issue. I can't confirm the problem you are having because I don't have a W2K machine running. Have you tried this on another machine (client machine perhaps?) This could still be something specific to your environment. If you can repeat this consistently, then you've got yourself a bug. I can't imagine that after all this time it has not been discovered and either dealt with or "dealt with", but you never know.
Wish there was more I could offer...


Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[Brak]

I find it odd as well that it hasn't been mentioned before considering Win2000 has been out for a few years.

The only access I have to a Win2000 machine is the one that currently made me aware of the issue.

Hopefully someone here on this forum has Win2000 and will be willing to check it out. I want to make sure someone else is able to replicate to problem before I contact MS.

 

[Scott24x7]

If I can get my hands on a W2K build, that I can put VFP onto, I'll give it a taste, so stay tuned to this space.


Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[dbMark]

Do any of these threads help?
thread182-1177423 - references to other unexpected drives such as E:, etc.
thread182-1112326 - Windows 2000 security updates and other potential causes
Awaresoft reports something like your problem here:
thread182-1036574 - GETFILE() drop-down shouldn't list invalid/incorrect drives
---- and other suggestions (avoid computers which have short 8.3 filenames turned off)

Windows 2000 was always a little quirky and awkward with certain DOS-Windows relationships and is nearing it's own end-of-life, so I'd recommend using XP instead because you may never find a great answer and maybe not even a reliable workaround.

dbMark

 

[Brak]

Thanks Scott.

I just noticed another thing which I just stumbled upon.

After you start the EXE, if you minimize the screen or click away from the screen, and then restore the screen or click back to the screen - then it works!

So basically if you cause the program to lose focus, when it is given focus again it works just fine.

Wierd stuff!

 

[Brak]

Mark:

Thanks for the links. I checked them out and they don't have anything To do with my problem.

Allow me to clarify something in case I wasn't clear before. It's not a problem with just the =GETFILE(), but rather any list or popup. I just suggested people can verify the error using the =GETFILE() function for the following reasons:
1: It includes both a list and a popup
2: It elimiates any kind of "programmer error" in the creation of the screen - as it is a MS creation.

Some weird stuff.

 

[Scott24x7]

Brak,
Well, that's cool... at least you have a viable work-around?


Best Regards,
Scott

"Everything should be made as simple as possible, and no simpler."

 

[Brak]

Not really a work around, as it causes the user to do something they should have to do for the app to work - minimizing the screen or selecting another program or screen as the focus.

But this raises a question which could be a work around:
Is it possible, code wise, to make the app lose focus and regain it. Basically to have it so that when the app starts it minimizes and maximizes automatically without any user intervention.

Before i go any further i want to wait for a confirmation from someone on the forum that this is a FPW26/Win2K bug, and not a "just on my machine bug".