In my opinion, yes. If you want the default behavior, then do not
attache anything else to it, otherwise, do it all in your own code.
Douglas Staas wrote:
Ok, so due to the rescheduling of threads, sometimes an "OK" button's events
get fired as expected and sometimes the dialog is closed before those events get run?
Does this mean that binding code to OK button events is generally a bad idea with Open
Office? I'm just trying to understand. This subtle quirk appears to be unique to Open
Office. Is this something that'll be addressed some day?
thanks
doug
An "OK" button performs a default action. so, you think that it should
only do what you told it to, but in reality, it is ALSO doing the
default OK action, which you did not expect because you did not know
what an OK button was.
Douglas Staas wrote:
Thanks to Paolo and everyone else who's offered ideas. Paolo's fix worked.
11.3.3 appears to be very general. I don't see how it applies to this specific
scenario. Then again, perhaps understanding the difference between an "OK"
button and a "Default" type button would help. If so, where could I find
documentation on that? ie: Where can I read about OK buttons causing a dialog to
close before associated events are fired?
Thanks, again. I'm sure I'll have more questions as I digest this and proceed.
doug
Hi Douglas,
Alle 19:16, giovedì 10 novembre 2005, Douglas Staas ha scritto:
My questions keep piling up. If this isn't the right place to ask them,
where should I seek answers/useful documentation? If this is the right
place to ask them, what do I need to do to engage in a dialog about these
issues?
* Macros don't run when a 2nd OO file is open unless the macro editor is
open. When will this be resolved?
I don't want to dig into details but ony let you know that IMHO your macro is
not well conceived and perhaps your problem is only a side effect of that.
1) You have manually binded the events keyPressed and MousButton-pressed to
the SetAllTexts subroutine
2) You have set the OK Button as Button Type = "OK"
I think that your problem is due to the fact that the 2) causes the dialog to
close before the events has been raised.
This is the normal behaviour and you can find a detailed explanation of that
in the DevGuide at:
11.3.3 Special Behavior of OpenOffice.org Basic
Rescheduling
BTW the DevGuide shows an example that covers exactly your situation.
However, my suggestion is to remove the binding of events and modify your
"PromptForValues" as shown below.
--------
Sub PromptForValues
DialogLibraries.LoadLibrary( "SlaySysLibrary" )
oDialog = CreateUnoDialog( DialogLibraries.SlaySysLibrary.SlaysysDialog )
If oDialog.Execute() = 1 Then
SetAllText()
End If
end Sub
--------
hope that helps
PaoloM
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.sxw
My Book: http://www.hentzenwerke.com/catalog/oome.htm
Info: http://www.pitonyak.org/oo.php
See Also: http://documentation.openoffice.org/HOW_TO/index.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
My Book: http://www.hentzenwerke.com/catalog/oome.htm
Info: http://www.pitonyak.org/oo.php
See Also: http://documentation.openoffice.org/HOW_TO/index.html
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
