Delete_record() confirm dlg

[Scott Emerick]

Hi All,

Is there any way to know if a user canceled the delete record from the confirmation dlg that comes up using Delete_record() ?

Thanks,

Scott

[Stan Mathews]

RE: Delete_record() confirm dlg

I think you'll have to change your code to use tbl.delete() like


response = ui_msg_box("Question", "Are you sure you want to delete this record? ", UI_YES_NO)
if response = UI_YES_SELECTED then
dim tbl as P
tbl = table.current()
tbl.change_begin()
tbl.delete()
tbl.change_end(.T.)
'probably need to resynch the form here
elseif response = UI_NO_SELECTED then
' some other code here
end if
end

[Scott Emerick]

RE: Delete_record() confirm dlg

Stan,

Hi, yes I thought about that but I have so many forms that are using a function that uses delete_record() that I cringe the thought of having to change everything. I really am getting annoyed with the problems that's are happening with the conversion to V6. I would think that the functions that worked in V5 would be the same and V6 and the are not. The whole timing is different in V6 opposed to V5.

Something that I notices with V6 is that if you have a script that calls a UDF, the script complete's before the UDF finishes. I have tried XBASIC_WAIT_FOR_IDLE() and XBASIC_ASYNCHRONOUS(), both do nothing to stop the script from completing.

Thanks for your help,

Scott

[Tom Cone Jr]

RE: Delete_record() confirm dlg

Scott,

If you have a working example that's different from behavior in v5 I think Alpha would like to see it. You might consider sending it along to them.

I haven't noticed any difference in how the "object".delete_record() method works in v6. What are you seeing that's different?

-- tom

[Kevin McDuff]

RE: Delete_record() confirm dlg

Hi Tom,
I asked Selwyn about this problem and presented an example that showed a form with a child browse and a Delete button that included the code:

parentform:Browse1.delete_record()
parentform:Browse1.fetch_first()

In Version 5, if a record in the browse was selected other than the first record in the browse list, the Delete button would delete the selected record, then fetch the first record in the browse list. In Version 6, the first record is fetched before the deletion is made, so the first record ends up being deleted rather than the selected record.

When xbasic_wait_for_idle() was added between the two lines, it made no difference.

Selwyn suggested that the code be changed to:

browse1.activate()
parentform:Browse1.delete_record()
code = topparent.name() + ":browse1.fetch_first()"
on_xbasic_idle(code)

Selwyn said:
the reason that this is necessary is that the browse.delete_record() method has User Interface, and waits for an idle. So, the .fetch_first() is happening before the delete completes. It would be very hard to know exactly what change in v6 causes this to behave differently than V5, and we would likely break something to even try to fix this.

the reason that we had to do
code = topparent.name() + ":browse1.fetch_first()"
on_xbasic_idle(code)

and not

code = "topparent:browse1.fetch_first()"
on_xbasic_idle(code)

is that when on_xbasic_idle() executes the registered code, it does not have any context.

(And an interesting follow-up note: This morning, xbasic_wait_for_idle() seems to be working as expected and solves the problem--although we'll stick with Selwyn's suggested code.)

[Tom Cone Jr]

RE: Delete_record() confirm dlg

Kevin, thanks. I was unaware of what you describe. It occurs to me that this might be a good approach whenever our scripts use form level methods to manipulate the underlying table "through" the form, instead of doing so directly.

Thanks again.

-- tom