ello chums,
Seems like this should be straightforward but Im drawing a blank on this. I’d been noticing some odd behaviour with the event handlers of the flowlayoutpanel. I’m using this as a dotnetcontrol, and then populating it with dotnetobjects (buttons). This is fine when working as a rollout floater, the dotnet event handler registers okay and fires off as expected. I seem to remember that the dotnet event stuff needs to be in global scope in order for it to work.
However, if i place the same rollout within a custom attribute, it appears that the event handler goes all screwy and doesnt register in the same way.
worky –
rollout dotnetscopetest "Me Likey!" width:160 height:160
(
fn buttonhandler sender args =
(
format "button pressed! - %
" sender.text
)
fn BuildPickUI index =
(
flowbutton = dotnetobject "button"
flowbutton.flatstyle = (dotNetclass "System.Windows.Forms.FlatStyle").flat
flowbutton.Margin = dotnetobject "System.Windows.Forms.Padding" 0
flowbutton.size = dotnetobject "System.Drawing.Size" 75 30
flowbutton.FlatAppearance.MouseOverBackColor = (DotNetClass "System.Drawing.Color").Crimson
flowbutton.text = ("button " + index as string)
dotnet.addeventhandler flowbutton "click" buttonhandler
return flowbutton
)
dotNetControl flpDisplay "System.Windows.Forms.FlowLayoutPanel" pos:[3,4] width:150 height:150
on dotnetscopetest open do (for i = 1 to 10 do flpDisplay.Controls.add (BuildPickUI i))
)
createdialog dotnetscopetest
no worky –
DotNetscope_Attr = attributes DNScope
(
rollout dotnetscopetest "No Worky!" width:160 height:160
(
fn buttonhandler sender args =
(
format "button pressed! - %
" sender.text
)
fn BuildPickUI index =
(
flowbutton = dotnetobject "button"
flowbutton.flatstyle = (dotNetclass "System.Windows.Forms.FlatStyle").flat
flowbutton.Margin = dotnetobject "System.Windows.Forms.Padding" 0
flowbutton.size = dotnetobject "System.Drawing.Size" 75 30
flowbutton.FlatAppearance.MouseOverBackColor = (DotNetClass "System.Drawing.Color").Crimson
flowbutton.text = ("button " + index as string)
dotnet.addeventhandler flowbutton "click" buttonhandler
return flowbutton
)
dotNetControl flpDisplay "System.Windows.Forms.FlowLayoutPanel" pos:[3,4] width:150 height:150
--the timer is a hacky way of invalidating the dotnet control in the comand panel, as without it yields a blank UI
Timer Refresh "" pos:[141,241] width:24 height:24 interval:1
on dotnetscopetest open do
(
for i = 1 to 10 do flpDisplay.Controls.add (BuildPickUI i)
refresh.active = true
)
on refresh tick do
(
flpDisplay.refresh()
refresh.active = false
)
)
)
custAttributes.add (modPanel.getCurrentObject() ) DotNetscope_Attr #unique
anyone found a way around this?
that is the strangest thing. I even made the callback function global, referenced the buttons directly out of the flipdisplay, and then added that callback using an ‘execute’ command… from within the timer’s tick event. Which should mean that it is…
A. outside of the initialization routines (thanks to the timer tick)
B. in the global scope (thanks to execute)
C. referencing everything directly (explicit references, no passing variables)
… and yet, nothing happens. As soon as I run the same line as the execute does in the Listener, it works fine.
Just like the proverb: If a timer ticks but it doesn’t trigger its event handler…
Thanks Rich, I hadn’t tried the timer method but that’s the results I had too. Might be one to log with Autodesk.
p.s. – I have a custom class library that does a similar thing with a flowlayout control and that functions fine within the command panel, so it must be something max is doing.