[Closed] structs, rcmenu's, and rollouts
I have a primary struct, with a few rollouts, and rcmenu all embedded inside it.
My problem right now, is passing information between the three. I’ve done a “hack” of passing information to the rollout after its Dialog has been launched. I do this because it seems any information, such as data pointers, i pass into it before the Dialog is created gets cleared at the “createDialog” call.
But with my rcMenu, though not completely tested, it seems i don’t have the option to do that same”hack” because when the dialog is created, its running its code, and i’m unable to get out of it to pass in the new information/data pointers.
If any of that makes sense.
Is there a better way to talk between these 3, without using the obj instance of the struct as a pointer, or am i completely missing something?
Thanks
Here is a snippet that shows how to share the data of structure, rcmenu, and rollout:
struct comboStruct
(
private
rc,
top,
rol,
public
pos = [100,100],
size = [200,100],
checked = off,
text = "The Button",
-- make Top Menu
fn makeTop =
(
rcmenu ComboTop
(
local d = if d != undefined do d
submenu "File"
(
menuitem active " Position is less then 500" checked:((getdialogpos d).x < 500) enabled:off
separator sep1
menuitem exit_it "Exit"
)
on exit_it picked do destroydialog d
on ComboTop open do
(
format "RCTop calls:
"
format " struct: %
" this
format " rcmenu: %
" rc
format " rollout: %
" rol
)
on ComboTop update do
(
active.checked = (getdialogpos d).x < 500
)
)
),
-- make Right Click menu
fn makeRC =
(
rcmenu ComboRC
(
local owner = if owner != undefined do owner
local can_check = if can_check == undefined then on else can_check
menuitem check "Check" checked:owner.checked enabled:can_check
on check picked do owner.checked = not owner.checked
on ComboRC open do
(
format "RCMenu calls:
"
format " struct: %
" this
format " rcmenu: %
" rc
format " rollout: %
" rol
)
)
ComboRC.owner = this
ComboRC
),
-- make Rollout
fn makeRL =
(
rollout ComboRol "Combo Rollout"
(
local owner = if owner != undefined do owner
local bsize = if bsize == undefined then 100 else bsize
button bt width:bsize
on bt rightClick do owner.openRC act:on
on ComboRol close do
(
owner.size = [ComboRol.width, ComboRol.height]
owner.pos = getdialogpos ComboRol
)
on ComboRol open do
(
bt.text = this.text
format "Rollout calls:
"
format " struct: %
" this
format " rcmenu: %
" rc
format " rollout: %
" rol
)
)
ComboRol.owner = this
ComboRol
),
fn openRC act:off =
(
rc.can_check = act
popupmenu rc
),
fn openRL bsize:undefined =
(
rol.bsize = bsize
createdialog rol size.x size.y pos:pos menu:top lockHeight:off lockWidth:on \
style:#(#style_border, #style_resizing, #style_titlebar, #style_sysmenu)
),
fn destroyRL = if rol.open do
(
destroydialog rol
),
on create do
(
rc = makeRC()
top = makeTop()
top.d = rol = makeRL()
)
)
a = comboStruct()
a.openRL()
/*
a.destroyRL()
a.text = "Right Click It"
a.openRL bsize:160
*/
Hopefully I didn’t forget any possible types of the sharing data…
PS. Don’t forget to define your own structure’s Clone method.
Use global variables. They are accessable from every script.
Add this at begining of your script(s):
if( MY_SCRIPT_VAR1 == undefined ) then -- globals not created yet
(
global MY_SCRIPT_VAR1 = 4
global MY_SCRIPT_VAR2 = 6
global MY_SCRIPT_VAR3 = "initial value"
global ...
)
Use most unique names as possible (make sure any other script no use globals same as yours)
correct global is the way to go here but not multiple ones, only the struct.
then inside your ROs ect access the struct’s items from a global level (struct.RO)
not in a local scope inside the struct (RO)
I was trying to avoid global variables. : (
It just seems wrong, programmaticly, to have to call a global variable for an object to get access to data thats right next to it. To me, it would be like calling the mayor, to get in communication with my roommate, in the next room.
Found a decent work around, without using a global variable
I have a local property value in the UI, and when one of the options is picked, I just flag it with a value corresponding to that solution. Then I just access the flag from outside the dialog after it closed its displayUI.
A little crude, but i like that option much better.
Hi Dan,
This is how I did it as well. Do you instance the struct before you work with it?
I found as well you can’t inject data in a rollout before createdialog is called, so I add it afterwards and have the rollout have a local variable called “this” or “self”. Same for menu’s.
I now have abandoned that approach though, you always have at least 1 global variable for the struct or the rollout, I simply reference that from the rollout or menu, to get the data or functions I need, provided the struct is instanced, but that may not be what you need.
-Johan
what does this line do?
local owner = if owner != undefined do owner
Edit…
oh i see, it makes it so the variable’s definition stays preserved. Thats handy.