Using wildcard(*) in "With Thisform/Endwith"?

[kamweng]

The more I used VFP9 in my work, the more I realized I could shorten my coding by using certain command.

Now I wonder whether is it possible to use wildcard(*) in "With Thisform/Endwith". Take for example these codes -

WITH THISFORM
.SETALL("TOP",nTOP,"E1")
.W99.TOP = nTOP + 30
.M99.TOP = nTOP + 30
.S99.TOP = nTOP + 30
.I99.TOP = nTOP + 30
.Q99.TOP = nTOP + 30
.R99.TOP = nTOP + 30
.X99.TOP = nTOP + 30
ENDWITH

I would like to use THISFORM.*99.TOP = nTOP + 30 (It would not be worth while to further Class/Sub-Class it).

Is there other methods that is more suitable?
Any suggestions will be highly valued.
Thank you.

 

[Olaf Doschke]

First the help: .Setall("TOP",nTop+30 would do that, wouldn't it? You can and you may also not use the third parameter cClass to only influence a certain class.
Another solution would be to put the group of objects you want to shift equally into container and then only set the container top/left.
An elegant way to let controls react to Setall individually is to define new properties with ASSIGN method, eg you define lTranslate and in an lTranslate_assign method define code looking up a translation for this.caption or this.value or the list of data displayed, individually. You can then trigger all elements of a form to translate by Setall("lTranslate",.T.), this is the layman's way to create events in VFP.

Now a little criticism: It's bad to name objects numbered, though we don't have object arrays, there are a number of controls to display arrays or lists of controls, one is the grid, there are optiongroups, buttongroups. As an excuse VFP seeds that habit by numbering controls you add as eg Textbox1, Textbox2,... But if that exceeds 4 it's already a sign you need something else.

Classes come to mind, if you have groups of controls repeating, start a class based on container or even on the control baseclass. You might still end up with 99 containers on your form, each with a w,m,s,i,q,r and x control in it, but it's already much better organised.

Bye, Olaf.

 

[Olaf Doschke]

Some more inspiration: You have an Form.Objects collection you can loop via For Each loControl in Form.Objects and then also recurse, if loControl has it's own loControl.Objects collection, which is the case for containers, pageframes, grids, etc.

Also see

http://mobile.universalthread.com/ViewPageNewUserGroupMeeting.aspx?ID=34952

Bye, Olaf.

 

[kamweng]

Thank you for your fast replies. I will need time to digest your suggestions. Thank you once again.

 

[Mike Lewis]

Kamweng,

Olaf has already given you some good advice. I'll just add a couple of words.

First, in answer to your original question: No, you can't use wildcards in the way you suggested. In other words, the following is not valid syntax:

THISFORM.*99.TOP = nTOP + 30

A possible solution would be to use macro expansion, as follows:

1. Name the controls something like: W1, W2, W3, ..., W7.

2. Do the following:

WITH THISFORM
  .SETALL("TOP",nTOP,"E1")
  FOR lnI = 1 TO 7
    lcX = "W" + STR(lnI, 1)
    STORE nTOP + 30 TO &lcX
  ENDFOR
ENDWITH

However, I would ask if this is a valid use of your energies. You say you want to shorten your code. In a case like this, is there really any benefit in doing that? By using the sort of loop I showed above, you will reduce the number of lines of code, but only by a small amount. The code might run a tiny bit faster (or it might not). But it will be less readable; it will take longer to code; and it is more likely to introduce bugs.

My overall suggestion is that you stay with your original code, except that you should use meaningful names for the controls, not things like W99 and M99.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[kamweng]

Many thanks to both of you.

I now realized my Excel style of naming the controls is not correct. Indeed my UI look like Excel, thisform.*99 being the names for the Total Value for each columns.

In fact, I switched from Excel to VFP but maintained the look of Excel. I have classed it so that I can use SETALL and then use WITH THISFORM to deal with the exception.

Olaf is correct in saying I have to many controls. I am taking his advice of using grid. I have not used grid before.

Off hand I would like to know, depending on condition, is it possible to show either date or value or text on each individual grid "cell"?

 

[Olaf Doschke]

> depending on condition, is it possible to show either date or value or text on each individual grid "cell"?
A grid column is a table column and so normally a column is just one type, a grid is not an excel sheet.

I could point you to the Dynamic properties of columns, eg DynamicCurrentControl could be used to display a date, numeric value or text. In conjunction with column.sparse = .f. you could override the normal column.text1 textbox showing the column controlsource value.

Another solution could be to have a text field, which can of course also show numeric values or dates as text, anything can be translated to text, eg by the TRANSFORM() function.

In the end table calculations are better done in excel, so if you port something from excel to a desktop application, this takes more than just changing from VBA to VFP language, a desktop application should make use of other UI. Eg data entry is typically done in labeled controls, specific to the data type.

It would be good to know the topic of your worksheets and see a sample to recommend how I would go about the same thing in a desktop application.

Bye, Olaf.

 

[kamweng]

Thanks Olaf,

My project is to build an app to replace the erroneous manual receipting for an high-rise apartment. I faced headwind because -
1) The users are almost computer illiterate.
2) Here, Solitaire is the killer app.
3) Words and Excel come next.
4) They have bought an accounting package but it is not suitable for them because of the above item 1.

When I joined them, I created a worksheet but it has limited use and furthermore only I know how to use it (not a good practice).

I chose the Excel style UI so that the users can accept office computerization more easily and give them no reason to reject it like the accounting package.

Another solution could be to have a text field, which can of course also show numeric values or dates as text, anything can be translated to text, eg by the TRANSFORM() function.

Indeed, I only have 1 form. It is make-up of classed non-editable Textboxes, Labels and command buttons. There is no data entry because the values are all fixed. They just have to select the items to be paid by the apartments' owners. This visual WYSIWYG style seem to suited them.

You are spot-on to say I have too many objects in my form. I will make use of grid and DynamicCurrentControl in my next version.

As always, you and Mike are my good teachers.

Thank you.

 

[Olaf Doschke]

OK,

first I have to add, that "data entry is typically done in labeled controls, specific to the data type" was a rather stupid way to describe the general nature of desktop applications. More to the point would be to say you can guide users through a process and have forms resembling the normal workflow.

OK, as far as I understand you're talking about putting together the prices for rented nights, other services. Done on paper the receptionist would simply write that on a sheet, with the price and the amount, multiply, sum, done.

As a form I'd display a list of available items to choose from (eg double/single room, breakfast, lunch, dinner, mini bar items, whatever), let the receptionist pick from that to another list of picked items and enable to enter a multiplicator. To make this less rigid you could allow to enter an individual item not listed as free text and an individual price, eg also negative to compensate for complaints, etc.

For the picklist you could use a grid, but also a listbox the lis of picked items should be the same control, first empty. You add picked items with an amount/number of units and that would be that.

To make the picking process as easy as possible, add a number to each item, eg 2 digits, 01,02,...99. If using a combobox for picking, users knowing the number of certain items could then pick them by just entering these two digits, which speeds up the picking process. You might also add a textbox above the grid/combo/listbox to let users enter the digits and/or enter any part of the item name, then SET FILTER TO Thisform.Filtertextbox.value $ itemname will filter the item list to easier find what you search and pick it.

Bye, Olaf.

 

[kamweng]

Duly noted.

guide users through a process and have forms resembling the normal workflow

I like the above quote because it describe what I am trying to do!

 

[Olaf Doschke]

Thanks,

there are two extremes with this general goal, though. If users are used to fill in a form manually, putting that form into an excel sheet is no progress. Youlimit the user anyway, eg with pen and paper, he can draw things, you could resemble that to some extent, if the user knows how to add a graphic into the excel sheet.

The other extreme is you "streamline" the workflow and let a user only do the core stuff and only in a certain predefined order.

"To guide" a user is somewhere in the middle. There has to be a compensation for the uncomfort of not being totally free anymore, like you have been with pen & paper, perhaps. The users have to get aware of these benefits to agree, this is worth the effort to learn the software, no matter if it's your own or some software off the shelve. They have to be motivated to learn and do some prework, eg to enter a list of items and their prices once, to benefit from the "computerisation" of this process.

Calculating 100% correctly is one of these benefits, a filtering, which helps finding things easier is another benefit, not needing to remember prices, having documented your work, being able to make this searchable in case of a complaint coming in months later etc etc.

Bye, Olaf.