Canceling methodolgy for sets

[DaveM]

Re: Canceling methodolgy for sets

I use a utility(my word) script on close of the database that checks the tables for blanks and deletes all blank table fields. This applied to the tables I have found with that problem.

[danh]

Re: Canceling methodolgy for sets

MikeC,

If I am understanding your solution correctly, you are talking about opening up the child record(s) in a separate form and canceling or saving each child record individually. What about a form with an embedded browse where the user can change the parent record and/or one or more child records directly from the open form, as in Alpha Sorts invoice form? Any ideas??

Dan

[MoGrace]

Re: Canceling methodolgy for sets

Just a note about Quickbooks. I am guessing that there is a flag set when a new record is entered even though the record is saved during data entry (it can be printed eg.); the flag is not "committed" until the user either moves off the record or uses one of the save buttons. Such a flag would help in determining whether posts occur or not. Since QB seems to make deletion/ clearing of records while still on the record, pretty effortless. The setting of such a flag dependent upon mode would not be that difficult. QB is probably trapping all the navigation keys to test the setting of this flag.

Just my thoughts.

[MikeC]

Re: Canceling methodolgy for sets

Dan,

I think Robin is Correct in how it would be set up. There is no easy way to set a variable to more than just the one record that is changed...but if this was a case in which it HAD to be done, I think with a lot of script it could be accomplished. I really don't think it would be worth the effort. Stick to being able to cancel only one child and one parent record as it is not that hard to do this with the method I use or the others that have been suggested. In the child embedded browse you refer to you would have to make it so that if a record was edited or changed then the only way to cancel it would be prior to moving off the record--I experimented around with the sample I gave in attempting this and am close but when allowed to move off the changed record it gets a bit complicated (for me!! :) ).

Again, I would keep to one record (of parent and one of child) to cancel.

[danh]

Re: Canceling methodolgy for sets

Maybe I am being difficult, but I'm really not satisfied with limiting myself to one parent and one child. I'll go back to my previous post; Why do I need to explain to my user (just for forms based on sets) that certain data is coming from multiple tables and therefore needs to be save individually? The user sees the whole form and all the data in it and doesn't know (or need to, in my mind) that it is from different tables and needs to be handled differently. I really want to come up with a way to cancel any changes to any data in the set.

The problem seems to be with the child records. Could you call multiples of the same variable for the child records from the CanRowChange (or similar) event of the embedded browse?

Or would I be better off from a secure point of view to copy all data to a different table/set and edit from there and then when saved, overwrite the data in the first table/set?

Also, just ran across something in the help file I thought was interesting. Look in the 'how to...' for "Tracking Changes to Table Fields". Could I use a form of that?

Dan

[MoGrace]

Re: Canceling methodolgy for sets

Dan,
If you are trying to implement the QB model for canceling a new invoice then add referential integrity to the set and do a delete on the parent record of the form. Because this is what QB does when you cancel - you lose the whole invoice. QB prompts the user to save and if No is selected then the record(s) are removed. All your button needs to do is pass a Ctrl-D.

But if you want to cancel changes to an already existing record then you will have to do something more involved - no way around that. The ESC key will cancel any changes that have not been saved - in the region in which it is used.

Perhaps there is something else that should be addressed as to why your users make entries they must cancel?

[Doug Page]

Re: Canceling methodolgy for sets

Just so it is not misunderstood, I am not trying to be offensive with this post.

I do not know the QB program or how it does things. I can understand what you are asking for in your request. QB don't make the millions of dollars that they do just by rolling code from STANDARD scripts. I am sure that they are writing a lot of very complicated code to do the things that they do to make things easier for the customer. Unfortunately, it is a fact of life with programming that if you want to make things easier for the user, it almost always equates into more work for the programmer. What you are asking for can be done in Alpha with a lot of coding. You would need to dig into the Xbasic and XDialog and get VERY familiar with each. eg) Roll your own dialog that will enter all data into variables, perform data checks as necessary along the way, save data when you want, clear child information upon saving the record and set the cursor to the starting object for the child data to continue.

I must agree with the other posters here that the way that Alpha deals with a basic form with child tables is the very best way that it should be done. It caused me untold grief while I have been learning A5 (it is a never ending avocation) as I too wanted more polished looking apps. That is until I appreciated the fact that there is more power behind this beast than any single person will ever be able to fully grasp.

My suggestion, whenever you hear yourself saying to yourself something like:

Why do I need to explain to my user (just for forms based on sets) that certain data is coming from multiple tables and therefore needs to be save individually?

Quickly slap yourself in the face and say something like:

If I new all there was to know about A5, what would be the best way to achieve what I want so that I can give my users an easier to use app.

Look up other possibilities in the docs and if you're not able to find an answer, come to the board and ask something like: "I have been creating my forms like this in the past and have found these limitations. This, however, is what I am trying to achieve. Is there a way that someone could point me in the direction of to accomplish my goal." Then I'll bet you'll see some pretty creative answers. Right now the way I am reading it, you are telling everybody that "I am doing it this way, this is the way I want to do it cause this is what I know, and I want it changed so that it works the way I want - why can't this be done!" The complexities of forms are fantastic but there needs to be logical rules behind them. As you can tell from the discussion here, most people believe the rules are correct for the vast majority.

You have had some very good creative thinkers on this board chime in here to give you some suggestions. I think it is time to go back and look over them and weed out the advice they have given. In the end, it doesn't hurt them if you don't heed the advice but they might not be as ready to continue the thread!

[danh]

Re: Canceling methodolgy for sets

"I am doing it this way, this is the way I want to do it cause this is what I know, and I want it changed so that it works the way I want - why can't this be done!"

I am sorry if this is the way I was coming across. Sometimes it's easy to write something and not realize how it may sound to someone else!

I am not trying to knocking Alpha's design, it is a very powerful program and I like a lot about it (this feature is not one of them, yet) :), and I was just using QB as an example. I was hoping I missed something when I read in the help file that sets are just like tables and then found out I can't cancel the same way. I was also hoping someone from Alpha would chime in and show what they had in mind for canceling changes to sets.

Perhaps there is something else that should be addressed as to why your users make entries they must cancel?

One example would be if a customer ordered several items and then called back to see about adding to or changing the order. The user could simply pull up the order, make the desired changes and give them a verbal answer and then cancel or save depending on the customers decision.

Anyway, back to the issue; looks like we have about 3 choices;

1) Use <tbl>.record_data_get() and....set(), simple, but with limits of one parent and one child, unless there is a way to repeat it for each child record.

2) Use variables on the form instead of fields attached to tables. Haven't worked with this type of form, so would need some help with this one.

3) Copy data to temporary tables, make edits in temporary tables and then write back to the primary tables. Would this be more secure? I guess the same as #2. If the user left the form open on their computer while editing and the electric blinked, changes would be lost, but the original record(s) would be left intact, right?

Am I missing any?
Any comments on these different (or others) approaches?

Dan

[MikeC]

Re: Canceling methodolgy for sets

Dan,
First, I think that unless a user is extremely new to any type of database, or application for that matter, most would not expect to be able to cancel something after moving on to a completely different record...I mean, if this were the expectation where would you stop?? After two records are created...10 records??....or maybe a week later??? (being a bit obnoxious now! :) ). There has to be a limit really. But if your users want something like this that is a different story and am sure it could be coded via any of the 3 ways presented to you.

1) Use <tbl>.record_data_get() and....set(), simple, but with limits of one parent and one child, unless there is a way to repeat it for each child record.

This could be repeated by having different Blob variables being assigned whenever a record changed and then either an all-out cancel performed or with maybe xdialog a list of choices could be made for the user to cancel only certain ones....this procedure would be the most difficult I am thinking to incorporate.

2) Use variables on the form instead of fields attached to tables. Haven't worked with this type of form, so would need some help with this one.

This is similar to the prior method that uses a Blob variable except that your fields now become variables and as the table fields are not set to these variables until you decide to, if the user decides to cancel there is nothing to do---that is you simply do not set the actual table value to the variable that was changed. To do this with multiple child records.....am not sure if this can be done easily either (if at all). To do this you would have to have some sort of method to change the field variable names so that they would be different for each different record.

3) Copy data to temporary tables, make edits in temporary tables and then write back to the primary tables. Would this be more secure? I guess the same as #2. If the user left the form open on their computer while editing and the electric blinked, changes would be lost, but the original record(s) would be left intact, right?

This is most likely the route to take as it gives you the opportunity to cancel a multitude of changes made, but am thinking this would be an all or nothing proposition. It may be possible to tag each record that is changed and then present the user with a list of the records and cancelling only the ones wanted...I believe it is doable but not for the really inexperienced person--

More secure?? I'm not understanding this I guess...you can prevent a user from doing any or all of any of the above procedures.

And yes, original records are not touched until they are....so if nothing has been written back from the temporary table then the original record has not been changed. I guess this is what you asked...?

I guess now it is up to you to decide on which method you want to pursue. Then when you are to a point where you get lost, come back to the forum and post your problem (in a different thread I would think).

[MoGrace]

Re: Canceling methodolgy for sets

I'll try to stick to the QB theme here ;). Your app ought to follow standard accounting principles - eg. when you write a check and need to change it, you must void it and write another. The same principle should follow for any records that are printed as verification to a customer. Now there is nothing that says you have to do things this way, but some decisions ought to belong to management and not the data entry person. You do not want your users deciding which orders and invoices they will delete if those records have already been sent to your customer, because they provide them proof and give you some control over where the money goes. Which is the beauty and potential harm of a computer system.

With manual records all papers are accounted for and any missing ones would be suspect of potential foul play. It happened to me once with a girl in the office who had written herself some checks and forged the signature. Had she not removed the cancelled checks from the bank reconciliation, I would probably not have discovered what she had done.

Obviously there is more to consider than just the ease of use of your program.

[danh]

Re: Canceling methodolgy for sets

OK, I will do some experimenting, and see what I can figure out from here.

Thanks to all who contributed.

Dan