Buttons not working

[Bill Harriff]

I wrote months ago about a problem with buttons on a form not working correctly and I still haven't got it fixed. I think the problem is related to how the relationship of the form changes as its used. When you open the form directly all buttons work. But when the table the form is attached to is opened for lookup and then a user decides to add/edit an entry on-the-fly, this form opens but is now probably a child rather than a parent as when opened directly. In this "role" the buttons return xbasic errors. I'm attaching a demo app to see what I mean. If anyone can re-code the buttons so they work in both roles I'd sure appreciate it.

To see what I mean, dl the attachment, then open the customer form & try the buttons; then open the Job Info form and when you get to the customer field do the lookup and then click the change button and when the form opens, try the buttons now.

Thanks for taking a look at this...

Bill

[martinwcole]

RE: Buttons not working

the job info table was empty
when I added two records to it I could toggle back and forth and all worked okay

[CraigSchumacker]

RE: Buttons not working

Bill:

When the form is opened from the change button, it is being opened as a dialog box reflecting (by design) only the record you clicked on to change. As such, the 'next', 'previous', and and 'change to table view' buttons will never work.

For this reason, I might create an exact copy of the customer form using it strictly for the lookup form called for in the field rules. You could then leave off the buttons that won't work in the situation mentioned in paragraph one.

To make the other three buttons work, change the words 'parent' and 'topparent' to ':customer' on the action scripts for those three buttons... The dialog form isn't recognized as the parent or topparent, and by using ':customer', you are directly identifying the form in your declaration. Of course, if you use my suggestion in the second paragraph, you will need to change ':customer' to ':thenameofyourlookupformhere'.

I hope this helps. I've never considered myself a great author, and my instructions often leave people scratching their heads. This is probably no exception!

Craig

[Bill Harriff]

RE: Buttons not working

Craig,

Thanks for your ideas about duplicating the forms - I did that and things work much better. This app has 8 table lookups where users can pick from other lists, but also get in and edit/all on-the-fly so it took a bit of time. Beyond fixing the error msgs. it was a good opportunity to clean up/standardize the lookup forms. Your explanation of the form being used as a "lookup dialog" cleared up much of my misunderstanding about what was going on. I think my customers will be happy to not see the error msgs. anymore also. But, they do prefer viewing/working with their data in a browse table rather than a form (they used to do all of their work in spreadsheets), but I'll encourage them to update inventory, customers, etc. from direct access via the main menu rather than while entering a new docket.

I do have some other questions that are related to this tho...
- I wound up creating 8 add'l lookup forms; what kind of "overhead" does this add to an application?
- button behavior is what I consider to be weird or less than perfect in just about every app I've developed and even in samples that I've downloaded from the Phorum. Record nav. buttons are a good example: often I get complaints from users that a single click on a First/Last/Prev/Next Rec. button will work, but the next single click won't. They must click it again to get the advance. Sometimes even a third click. I've not paid much attention to button behavior during devel. but I am now as I hear a fairly steady stream of minor complaints about it. Now that I'm looking, sure enough that's what is going on. I see it across a wide variety of systems (PII-300's w/64mb up to P4 or AMD 1800's with 512mb), so it looks like either something I'm doing as I devel., or it's A5's std. behavior. But I always just use the button genie which is mainly canned action scripts or very simple xbasic code. Any ideas about what causes this and what's a fix?

Again, thanks for your suggestions and info.

Bill

[Bill Harriff]

RE: Buttons not working

Martin,

It sounds to me like you where just looking at the first level of lookups from the Job Info form. The problem I was working on was what happened after you brought up, for instance, a lookup based on a related table (customer.dbf) and then, while in that lookup table, decided you want to change something about a specific entry in that table or wanted to add a new customer to the lookup table. If you then click on the Change button at the top right of the lookup window then another window opens which is the Customer form (not the job info form). The buttons on that form return xbasic error msgs. Craig's answer explained why and has the fix.

Bill

[CraigSchumacker]

RE: Buttons not working

Bill:

There is no 'overhead' in having several forms, whether some are variants of others or not.

The only cost is on the developer's end, as changes done to one may need be done to it's cousin form. You probably want to be consistant in the naming of the lookup forms, so the can easily be identified by the developer.

I can't think of many cases where you would need two almost identical forms. Your case, with using the field rule lookup, is one. There are ways to call the exact same form using XBasic to hide the non-functional buttons, the on arrive event, global variables, etc., but I see no point in doing all that when the end result will be the same with less work required on the developer's end.

As far as your customer's are concerned, that's not really the best place to do maintenance on the lookup table, other than for the lookup record from which they are acquiring data from at that time. It seems to me that, when entering data, the operator should focus on one record at a time, do it well, and the move on to the next record. Stopping in the middle of entering a record to do a lot of maintenance on another table is inviting a higher than normal level of data entry errors, at least by my mindset!

If your customer insists that you set it up their way, it can be done, but at a much higher cost to them.

Bill, as far as the button issue, I'd need to see an example. I can assure you that working buttons are possible, though. If you post an example, I or someone else will take a look. Action scripting is great, as is the script recorder, but some fine tuning is sometimes needed...

Craig

[Bill Harriff]

RE: Buttons not working

Craig,

Editing or adding info on the fly is typical in everything I've ever done and in this case I think it's appropriate. This is a job cost module that pulls line items into a child table/embedded browse which gets its prices from g-child inventory table (operations or materials). The relationship looks like this >> [Dockets.dbf]======[Ink_Costs.dbf]-----[Inks.dbf]. Right in the middle of entering, for instance, a ink line item for Black, AT11487 the user notices that the price is out-dated. Instead of exited the main form and returning to the main menu to access the form for Editing/Adding Inks, she hits the change button and does it on the fly, then accepts the item into the embedded browse and finishes by putting in the amt used, then the line item cost field calc's on the correct amt. I think that's pretty typical behavior in QB or Peachtree, esp. when the user is the person who also maintains the price lists. I realize in companies that have back office staff that maintains the inventory/price updates, this is not appropriate, but we're talking about a small office staff here. The app also has a Quote module that I've just started to setup for the sales staff. This will share the same inventory tables and we're talking about how much access to give them in regards to updating prices or adding new items. My pref. is to have 1 person maintaining the inventory tables (the woman doing the job costing), but limit sales to just lookups. Buttttttttttttttttttt, they're not liking that so far. The compromise will probably be one where I'll wind up setting up granular user rights and then give the head of sales access to updates but not the other reps. It's a small family-owned printing co. with little staff turnover and everyone is very "trusted." Real different than my med. practice customers.

Thanks for you ideas about this.

Bill

[CraigSchumacker]

RE: Buttons not working




You said:
"Editing or adding info on the fly is typical in
everything I've ever done and in this case I think it's appropriate. This is a
job cost module that pulls line items into a child table/embedded browse which
gets its prices from g-child inventory table (operations or materials). The
relationship looks like this "" [Dockets.dbf]======[Ink_Costs.dbf]-----[Inks.dbf].
Right in the middle of entering, for instance, a ink line item for Black,
AT11487 the user notices that the price is out-dated. Instead of exited the main
form and returning to the main menu to access the form for Editing/Adding Inks,
she hits the change button and does it on the fly, then accepts the item into
the embedded browse and finishes by putting in the amt used, then the line item
cost field calc's on the correct amt. I think that's pretty typical behavior in
QB or Peachtree, esp. when the user is the person who also maintains the price
lists."
I Said:
"As far as your customer's are concerned, that's not
really the best place to do maintenance on the lookup table, other
than for the lookup record from which they are acquiring data from at that time."
This is typical and expected. Your example indicates
exactly what I was saying. However, your customer lookup form had
'Next', Prev', and 'Change to table view' buttons. These buttons would
allow the entry person to "lose focus" from the CHILD record she is
trying to fill in. This is why A5 opens your lookup form, or their own
default lookup form, as a dialog box. By doing so, focus is maintained on
the CHILD record that the LOOKUP record fills in.
You said:
"I realize in companies that have back
office staff that maintains the inventory/price updates, this is not
appropriate, but we're talking about a small office staff here."
Bill, I don't think the size of the company is
relevant, this is more a process of logical procedure. If
"Christine" has ten price changes, It makes sense, to me at any rate,
for her to change those 10 prices as soon as possible, and not while 'on the
fly'. By changing those ten prices right away, she assures all future
child records will be filled in from the lookup correctly. 'On the fly' is
always available, but it should be your 'second line of defense' in accurate
data entry. 'On the fly' should be done on a line by line basis, again, in
my opinion. Hence, no need for the three buttons 'Next',
Prev', and 'Change to table view'. I would have a separate button on the
application to allow access to your form with the three
buttons, and this would be the place I would
encourage general maintenance to be done.
In your current plan, I believe that Christine, in order to
change those ten prices, must start data entry in a completely different table,
go to the lookup field, open the lookup form, and make the ten price
changes. This just doesn't seem like the right time and place for general
maintenance.
You said:
"The app also has a Quote module that I've just
started to setup for the sales staff."
That's funny! Just started one of those myself this
week!
On re-reading my post above, what I was saying is clear to me,
but perhaps, by the way I write, others interpret my words differently. I
apologize if this was the case, as you obviously spent a lot of time posting an
example that illustrated what I was saying, more or less.
Have a great weekend!
Craig