Form problem 1

[dmusicant]

I have an app that I've run for 20 years, initially created in FPW 2.6, I've run it in various versions of VFP with success, run it on VFP 9.0 these days. My issue, which I've posted about here before, is that when I return to the base screen (a screen created in FPW 2.6a), I very often get a column or row position error, i.e. the screen bombs after the subsidiary code is exited. I normally run this thing until I hit either of two buttons, the first of which returns me to the Command Window, the second quits VFP.

So, I've tried a few things but the column or row position errors keep happening, so today I decide I'm going to have a go at creating a VFP form for the base for my application. In the FPW version there are over 20 buttons, but alas I only use about a dozen these days so my VFP form that I created tonight has about a dozen buttons, including the two that either exit VFP or exit to the Command Window.

Everything's running fine, I think, except for the FIRST BUTTON, which launches a PRG that lets me setup a browse of a table. That PRG launches another PRG. An FPD type screen created with some @SAYs and @GETs, it has 8 buttons and a 3-selection radio button set. A selection on that generates another set of @SAYs and @GETs with the index on a table having been determined by the previous "screen"'s button selection. IOW, these aren't FPW screens at this point, just basically Foxpro for DOS type screens. Well, these aren't showing up at all using my new VFP form to launch the FIRST BUTTON. I get an immediate browse of the table I'm using, no order set at all, it's going to the bottom of the table. Not only that, there's no way to close the browse window! That browse window is in Form1. Control+W doesn't make the browse close. It's nutty. The code that works fine when launched from a button on my FPW screen so far will not run when the code is launched from the VFP form. I have to use the Task Manager to kill VFP.EXE. One of the other buttons brings up an FPW screen from which I launch browse windows but they behave fine and they are not in Form1, which appears to be the form of the base form. Why the other button's browse is not confined to Form1 I do not know.

I've tried a few things including putting this code in the FIRST BUTTON's click procedure:

THISFORM.HIDE
THISFORM.Release
=CAPSLOCK(.T.)
DO b.prg
ON KEY LABEL LEFTMOUSE
=CAPSLOCK(.F.)
ON KEY LABEL esc
DO FORM djform
THISFORM.SHOW

The other buttons on the VFP form run fine when I merely hide the form, or in some cases don't even bother to hide the form. Hiding didn't help here so I added the RELEASE, but that hasn't helped either. As you see above, I tried releasing and regenerating, I suppose that can't work anyway, because the procedure doesn't exactly exist after the release? Anyway, I'd think that after releasing the form the programmatic sequences started by b.prg would run OK, but they don't at all.

b.prg starts the whole setup for the browse of this table. But the whole thing is haywire, the FPD type info never happens. Any ideas, tips? Thanks!

 

[dmusicant]

My FPW opening screen that this form was created to supplant has a feature I'd like to create for the form. It's strictly an appearance feature. It makes the screen look 3 dimensional. It's achieved by creating a second duplicate screen, putting it "behind" the first one but slightly to the right and below and then coloring it dark. The effect is the look of a shadow cast by the top screen, which has all the buttons on it. I'm trying to do this with the form but I don't see a way to do it. I can't just click on and select the form, whose designation is Form1. Is there a way I can do this with a VFP form?

 

[Mike Lewis]

VFP doesn't have a built-in way of creating a form "shadow". The method you are already using is one that comes to mind. But keep in mind that the user can (by default) moves forms around, and perhaps resize them. So you would need a way of keeping your shadow form in sync.

This thread might be of some help: thread184-1444715

Also, the use of shadows in this way is very DOS / Windows 3.x. Because of the superior aesthetics in modern versions of Windows, it's not much used these days.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Dan Freeman]

It makes the screen look 3 dimensional

And it makes the screen look like it's from another era.

(Or, as we used to chide Tom Meeks, it looks like Vegas-style U/I!)

In the modern era (dating from, say, Window 3.0), there are standard ways interfaces should look. If your interface doesn't look that way, you're odd man out.

Think twice about being the non-conformist. It's expensive and a lot of work. (It can be done, but can you afford it?)

 

[Olaf Doschke]

There is an official windows themes shadow, eg the VFP command window has that:

But it's not "a duplicate screen" and even the original feature of FPW just repeats the margin part. Besides its already replaces with the flat style of Windows8, 8.1 and 10.

I second Mike and Dan, don't go about such styles, this won't keep customer or attract new ones at all. You'd need to go to Winforms conform themes to make your app look modern and ideally go WPF, which is out of bounds of VFP. So in that respect VFP overall is wrong, it just helps to reuse your code. As soon as the UI look is your most concern I'd do the big leap and move to new standards, even when considering the things that can be done by gdiplusx, you can do something that looks better than todays flat styles easily, but you'll not only stand out in the positive way. People with an affinity for the aesthetics of their application suite and maybe a corporate identity look will find applications in concordance with OS theming rules and throw out anything non conformant. All you suport is people having stayed at DOS/FPW.

Bye, Olaf.