How to determine if a DataWindow is dirty (has been modified)?
@maram
I have a small question regarding DW.
I have a window open in an MDI and the window contains a couple of DWs
both of which are updatable.
Now, when the user tries to close the window, I would like to
determine if the Window (i.e., DWs are dirty or have been modified)
and prompt the user to "save the changes or close anyway?".
I have implemented this by doing the "modifiedcount() + deletedcount()
> 0" stuff. This does NOT work because prior to this, I've got to do
accepttext(). The problem with accepttext() is that it triggers error
messages in ItemError event of the DW. I don't want to perform
validation. I just want to determine if the DW has been modified or
not.
Can any one pls let me know whether what am trying to achieve is
doable or not?
The biggest part has been done but this piece is missing and without
it, the whole application looks incomplete.
Thanking you in advance for your time.
Best,
-A
Arthur Hefti
at the end. See the help for more details.
Arthur
@maram
Thanks for your response.
That's true what you said. However, I have validation messages in the
ItemError event, so I can't just return 2....I have to return 1 in
some cases (CHOOSE-CASE-ELSE).
Thanks again Arthur, any other ideas?
Best regards,
-A
Ivaylo Ivanov
since the last form retrieval.
boolean ib_modified = FALSE
Then set this variable to TRUE on all editable DWs' EditChanged and
ItemChanged events. Also, turn it to TRUE in the scripts where InsertRow,
SetItem or DeleteRow is issued upon some of these DWs.
Set the variable to FALSE after successful Save (meaning Update() for all
DWs + Commit) or Retrieve().
So the rest is to check this variable on CloseQuery.
HTH,
Ivaylo
"@maram" <atmaram...@gmail.com> wrote in message
news:012da178-a8da-43df...@f16g2000yqm.googlegroups.com...
@maram
Thank you for your response.
Your point seems clear to me; let me go and put it in action and get
back to you with the results.
Best regards,
-A
On Nov 3, 11:10 am, "Ivaylo Ivanov" <n0_S_p_a_m_i.iva...@isy-dc.com>
wrote:
> Define boolean instance variable to track if something has been modified
> since the last form retrieval.
>
> boolean ib_modified = FALSE
>
> Then set this variable to TRUE on all editable DWs' EditChanged and
> ItemChanged events. Also, turn it to TRUE in the scripts where InsertRow,
> SetItem or DeleteRow is issued upon some of these DWs.
>
> Set the variable to FALSE after successful Save (meaning Update() for all
> DWs + Commit) or Retrieve().
>
> So the rest is to check this variable on CloseQuery.
>
> HTH,
> Ivaylo
>
> "@maram" <atmaram.mull...@gmail.com> wrote in message
Jeremy Lakeman
Better (perhaps);
instance vars;
boolean ib_suppress_errors=false
closequery;
ib_suppress_errors=true
ll_valid = dw_1.accepttext()
ib_suppress_errors=false
if ll_valid <>1 then
if messagebox('...','... validation errors ... Do you want to close
anyway?',question!,yesno!) = 1 then return 0
return 1
end if
if modifiedcount() +
...
event itemerror();
if ib_supress_errors then return 1
...
Ivaylo Ivanov
I don't think any AcceptText() and validation logic must be issued on a
window close at all, unless you have some Save logic there which is a
different (means "strange" <g>) interface decision, IMHO.
"Jeremy Lakeman" <jeremy....@gmail.com> wrote in message
news:9495acd2-2713-4cc5...@o9g2000prg.googlegroups.com...
Ivaylo Ivanov
... it's coffee time....
"Ivaylo Ivanov" <n0_S_p_a_...@isy-dc.com> wrote in message
news:4af0391e$1@forums-1-dub...
Roland Smith [TeamSybase]
accurate except for the status of the current column. You can check the
current column by comparing GetText to a GetItemString that pulled the
Original value.
"Ivaylo Ivanov" <n0_S_p_a_...@isy-dc.com> wrote in message
news:4af03966$1@forums-1-dub...
Ivaylo Ivanov
taking into account the current column as well (read my post).
"Roland Smith [TeamSybase]" <rsmith_at_trusthss_dot_com> wrote in message
news:4af08e75@forums-1-dub...
jeff
Editchanged fails ... and is not reliable:
- user starts to type, replace an entry.
- user decides to abondon change, and press esc.
- result, field is not changed - not changes to datewindow, modify count is
ZERO.
However, this flag at the editchange event level would be true ... unless
you are trapping escapes, cancels, undo's that could be programmed in to the
application.
- what if column values are changed with code ... the editchanged would not
fire, thus no setting the modified flag.
Your best bet is to rely on the buffers and focus on the other events to
help 'override' code that you do not want to execute.
Jeff.
"Ivaylo Ivanov" <n0_S_p_a_...@isy-dc.com> wrote in message
news:4af13b6d$1@forums-1-dub...
Ivaylo Ivanov
read my comments along your post:
> Editchanged fails ... and is not reliable:
??
>
> - user starts to type, replace an entry.
> - user decides to abondon change, and press esc.
> - result, field is not changed - not changes to datewindow, modify count
> is ZERO.
It depends on how you formulate the task. If we assume that every keystroke
within a field makes it "dirty", I don't care about future escapes. If you
want more precise logic, then a more complex solution might be needed.
> However, this flag at the editchange event level would be true ... unless
> you are trapping escapes, cancels, undo's that could be programmed in to
> the application.
If you didn't notice in my post, I suggest trapping cancels (meaning
Retrieve()).
>
> - what if column values are changed with code ... the editchanged would
> not fire, thus no setting the modified flag.
Again refer to my post - turn on the flag in the scripts performing
SetItem()
>
> Your best bet is to rely on the buffers and focus on the other events to
> help 'override' code that you do not want to execute.
Still not sure that this is the best bet, imho. Sometimes the flag is just
enough, sometimes the buffers are just enough, sometimes custom
buffers+flags or special hidden columns would help. Once again, nobody can
be sure which one is best for all situatons.
Kind regards,
Ivaylo