Wierd Problem with "Edit" flags

forum.gupta.bugreport (2005-2010)
arvindram11
United States of America
Posts: 555
Joined: 14 Apr 2019, 23:42
Location: Richmond, VA

Wierd Problem with "Edit" flags

Post by arvindram11 » 27 Apr 2005, 22:47

 Posted by:  Aravind Ram 

Setting the value of a data field by using the "Set" command removes the
Edit flag. I thought this was reported a long time ago, cannot remember
what the response was from Gupta/Centura. Can anyone recall? It looks like
a bug to me.

I can understand SW/TD not setting the "Edit" flag to TRUE when you paste or
use the "Set" command to explicitly set the value for a data field. But why
should it remove it? If the user has typed something in the data field,
then that is no longer queryable with SalQueryFieldEdit.

See attached example in SW 2005. The same is also true in all other
versions of TD, I believe.

Is this a bug? If not, what possible good it could be to reset the "Edit"
flag to FALSE?

Aravind

You do not have the required permissions to view the files attached to this post.

Karthik

Re: Wierd Problem with "Edit" flags

Post by Karthik » 27 Apr 2005, 23:49

 Posted by:  karthik 

Thats not a bug. The edit flag is used to determine whether the user
**last** edited the window. In your case, you did it. So it clears it.

BTW, it should set it to true if somone pastes a record. Are you sure
its not set when someone pastes it?. Dont think so because the an
application i wrote is designed around edit flags and i have tested it
by copy-paste.

Best Wishes
Karthik

Karthik

Re: Wierd Problem with "Edit" flags

Post by Karthik » 27 Apr 2005, 23:52

 Posted by:  karthik 

I checked it and its all right. It does set the flag when you paste a
record. The edit flag is used to control user actions.

arvindram11
United States of America
Posts: 555
Joined: 14 Apr 2019, 23:42
Location: Richmond, VA

Re: Wierd Problem with "Edit" flags

Post by arvindram11 » 28 Apr 2005, 00:25

 Posted by:  Aravind Ram 

Yes, you are right. What I meant was if you used "Set" command, the Edit
flag is not set. So the same way if you use the "Set" it should also not
clear the "Edit" flag.

For ex: the user types in Master in the email field and tabs out. Let's say
the application kicks off a timer event on this field and searches for email
ids in the database starting with Master and assigns masteryoda@purdue.edu
to the data field when the user is entering something else in some other
field. Now the "Edit" flag on the email flag is set to FALSE. This causes
problems.

I know there are many many workarounds to this. But am very curious why a
"Set" statement should also set the "Edit" flag explicitly to FALSE.

Aravind

Karthik

Re: Wierd Problem with "Edit" flags

Post by Karthik » 28 Apr 2005, 00:35

 Posted by:  karthik 

I know there are many many workarounds to this. But am very curious
why a "Set" statement should also set the "Edit" flag explicitly to
FALSE.>>

If it did not set it to FALSE, then it means that the last action of
editing the field was a user action. You would not be able to find out
whether the user made any changes to the field after the SET Statement
executed. Hence, its explicitly set to FALSE.

Best Wishes
Karthik

arvindram11
United States of America
Posts: 555
Joined: 14 Apr 2019, 23:42
Location: Richmond, VA

Re: Wierd Problem with "Edit" flags

Post by arvindram11 » 28 Apr 2005, 02:21

 Posted by:  Aravind Ram 

Yes, I guess.

Although the email example I quoted would be a use case where this would
fail, unless after a "Set" command, a SalSetFieldEdit was called.

I have a table window in the top portion of one screen and some data fields
below it to display more detailed information. The data in the data
field(s) change when the user clicks on the different rows of the table
window. When the user edits any data in the data field, I store it in
hidden columns in the table. If the user clicks the "Cancel" button, the
cancel push button class checks the edit flags of all fields in the form to
inform the user that edits exist as a warning message. But this fails
unless I explicitly set the edit flags to true after a "Set" message. And I
can't set this unless the user has made some changes to any data fields in
the first place. So something that I hoped would have worked with Gupta's
default flags has now become an exercise of storing an edited flag on a row
level in the non-editable table window, which I hate.

Oh, well. I guess you can't win all the time.

Aravind

Return to “gupta.bugreport”

Who is online

Users browsing this forum: [Ccbot] and 0 guests