Hi Lubos,
I think your approach with ExcelAsyncUtil.QueueAsMacro and using DIALOG.BOX is a good one.
You won’t be able to get the answer back from the ExcelAsyncUtil.QueueAsMacro call – that execution context is long gone by the time the dialog is shown.
I’m expecting the XlCall.Excel call to return either a number (1 since you have only one non-cancel button) or the boolean false (if cancelled). Then if it’s a number, the array should have been modified too. You’ll probably do the checking and initial processing inside the macro context. So more like this:
ExcelAsyncUtil.QueueAsMacro(fun _ ->
let result = XlCall.Excel(XlCall.xlfDialogBox, Functions.dialog)
// check result type here and whether ‘dialog’ array has been updated
// either finish processing here, or use another mechanism to schedule further work.
)
Write again if you don’t come right.
-Govert
--
You received this message because you are subscribed to the Google Groups "Excel-DNA" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
exceldna+u...@googlegroups.com.
To post to this group, send email to exce...@googlegroups.com.
Visit this group at https://groups.google.com/group/exceldna.
For more options, visit https://groups.google.com/d/optout.
Sorry – I think I mistook the documentation at a first reading.
If OK is pressed, the modified array will be returned from the xlfDialogBox call:
The dialog box definition table can be an array. If dialog_ref is an array instead of a reference, DIALOG.BOX returns a modified copy of that array, along with the results of the dialog box in the seventh column. (The first item in the seventh column is the position number of the chosen button or >of a triggered item.) This is useful if you want to preserve the original dialog box definition table since DIALOG.BOX does not modify the original array argument. If you cancel the dialog box, or if a dialog box error occurs, DIALOG.BOX returns FALSE instead of an array.
Also, it wasn’t clear from your question what you are doing now, but ExcelAsyncUtil.QueueAsMacro with the rest of the code should be safe to call from a ribbon handler, as a way to transition to a context where the C API is available.