Saving a form with scrollbars

[sdocker]

I am using VFP 9 on a Windows 8 64 bit platform.

When I make a change to a form and save it, then run it, I get a "Do you want to save Form xxx?" It doesn't matter if I use Ctrl-s, the toolbar icon, or the Save option on the file menu.
If the change was made to one of it's procedures it works fine. It only happens when I make a change to the from.

If I remove the scrollbars it works fine.

Any ideas why the scrollbar setting has this effect?

Sam

 

[craigber]

Sounds like an issue has been found, but 60 fields on a single form??? That's really way too much. It's difficult for the user because it's too much data at one time. I would rethink the design. That could even eliminate the need for scrollbars.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[Olaf Doschke]

A design with pageframes would also be possible. Your form mainlay has "ASSETS" on page1 and "LIABILITIES AND EQUITY" on page2, in a pageframe inside page1 you can have "CURRENT ASSETS", "PROPERTY, PLANT AND EQUIPMENT", and "INTANGIBLE AND OTHER ASSETS" as the three pages and in a pageframe inside page2 you can have "CURRENT LIABILITIES" and "LONG TERM LIABILITIES AND EQUITY" and that's it.

Divide et impera - this way your longest subpage has 7 lines with each 4 textboxes.

And line 24 "TOTAL LIABILITIES AND EQUITY" could even be below all the pageframes as the form footer.

The user then can't scroll through the whole form anymore, but he can do that in a report preview. You can design a report about 1:1 the pdf layout and then the user can scroll and zoom in and out in the preview - sufficiently enough, if you ask me.

While entering data you can only concentrate one cell anyway and you let the form change pages automatically after the last textbox of a page has been entered. It's easy enough to guide a user through the data entry without him needing the mouse while he enters all the figures.

Bye, Olaf.

 

[Olaf Doschke]

I was thinking you had a tougher design to do, for example take a look at german income tax forms:

https://www.formulare-bfinv.de/printout/034040_12.pdf

Even, if you don't understand a word, it's not even nearly a grid layout. Your job is easy compared to that, isn't it?

Bye, Olaf.

 

[sdocker]

Dear all,

The form maty be grid friendly, but I'm not used to working with grids. As I said, I will try it, and decide between a grid, a pageframe, or a scrollable form.
It is not a particularly tough design, just very voluminous.
Most of my users are accountants and are used to working with long accounting pad paper. And they can sometimes be very pedantic. For example, whenever they exit a screen thay are prompted with a Yes, No, Cancel messagebox regarding saving changes made. One user requested an "Exit and Save" button just to save 1 mouse click.

So, what may appear to be obstination on my part is really an attempt to keep the customers happy.

Thanks for all the input.

Sam

 

[Mike Lewis]

... really an attempt to keep the customers happy

That's really the key point. The solution you adopt must be the one the users are most comfortable with.

In my experience, a scrolling form is usually not a good choice, especially if the form contains fixed objects, such as navigation buttons and the like, in addition to the actual editable content. That's because you don't want those buttons or whatever to scroll out of site as the user enters data into the body of the form.

A better solution is to place the main content in a scrolling region of the form, so that the peripheral objects are always in view. In effect, that's exactly what a grid is.

However, that's just my experience. You know your users better than I do. The best thing you can do is to create some simple prototypes of the possible designs, and test those on the users.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[sdocker]

Mike,

Oncee again, I agree. I am leaning towards a grid. I just have to practice and become more proficient at it.

Sam

 

[Mike Lewis]

Sam,

You might find this article helpful:

http://www.hexcentral.com/articles/foxpro-grid.htm

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[Olaf Doschke]

If you're not familar with grids, on one side you just need to set recordsource to a table name or even simpler drag a table from a form's data environment onto the form, but the idea with containers etc are more advanced.

What could help you is a scrollable container instead of making the form scrollable, this will also enable you to have a fixed header and footer area of the form. You may simply put your form design inside the following container class made by Craig S. Boyd: [URL unfurl="true"]http://www.sweetpotatosoftware.com/SPSBlog/PermaLink,guid,df3cb71d-588f-4bc6-b63e-9c94017edd7f.aspx[/url].

Bye, Olaf.

 

[sdocker]

Thanks again.

I will surely look at them.

Sam

 

[craigber]

I disagree somewhat with Olaf. The solution should be the one that is the most productive for the users. Sometimes, a short period of pain to learn a different design results in long-term productivity enhancements. Users are the worst people to design the Ux, with programmers a close second.

Craig Berntson
MCSD, Visual C# MVP,

http://www.craigberntson.com/blog

 

[Olaf Doschke]

Well, craig, but my ideas about containers in agrid to contain a partial form and compose the overall forms, is an advanced idea not easy to do, if you're not at all familar with grids yet.

Knowing the PDF form layout, you can use the grid in a normal way. But then some here also disagree to use a grid as data entry control at all.

Sam has the design with the scrollable form and the scrollable container would be a faster solution to port that to a form with no annoying save bug.

If time is not of the essence here, of course learning the grid pays for this case and the future, it's certainly a most useful control of FoxPro.

Bye, Olaf.