UserData in TreeView Nodes?

[SamuraiCrow]

Is it possible to store UserData in a TreeView Node or Leaf class independently of the UserData of the TreeView class itself? If so, how do you successfully set and retrieve it?

[airsoftsoftwair]

Have you tried using MOAI.UserData for that?

[SamuraiCrow]

I tried but the syntax I used was:

Code: Select all

moai.Set(nodeLabel, "UserData", tableToStore)

Was that wrong?

[SamuraiCrow]

I found another way by using the UID value as a key in a global table.

[airsoftsoftwair]

I tried but the syntax I used was:

Code: Select all

moai.Set(nodeLabel, "UserData", tableToStore)

Was that wrong?

No, that's the right code. It works here. If it doesn't work for you, post a MCVE.

[SamuraiCrow]

I think MOAI.UserData is garbage collecting at the wrong times. Since I replaced the tree-node UserData, the stability of my code has improved remarkably. The only place I'm still using MOAI.UserData is to pass a table between the functions that open dialog boxes and there's still an intermittent bug there. It looks like it only happens when storing and retrieving the table variable because I see nothing else happening that's fishy. If I replace it with a global temporary variable and it suddenly works consistently, I'll know where the culprit was.

[SamuraiCrow]

Code: Select all

@REQUIRE "RapaGUI.hwp"

Global data={}
data["id$"]="app"
data["name$"]=data.id$
data["encoding$"]="utf8"

/*
**	Editor
**
**	Allows name of application to be changed
*/
Function p_Editor()
	Global ModalUserData=data
	moai.CreateDialog([[<?xml version="1.0" encoding="iso-8859-1"?>
		<dialog id="req" title="Application">
			<vgroup>
				<radio id="encode" title="encoding$">
					<item>UTF8</item>
					<item>ISO-8859-1</item>
				</radio>
				<textentry id="name" />
				<hgroup>
					<button id="ok">OK</button>
					<button id="cancel">Cancel</button>
				</hgroup>
			</vgroup>
		</dialog>
	]], "win")
	moai.Set("encode", "Active", IIf(data.encoding$="utf8",0,1))
	moai.Set("name", "text", data.name$)
	moai.DoMethod("req", "ShowModal")
EndFunction

/*
**	Copy Back
**
**	OK Pressed so copy back from the dialog
*/
Function p_CopyBack()
	ModalUserData.name$=moai.Get("name", "text")
	ModalUserData.encoding$=IIF(moai.Get("encode", "Active")=1, "iso-8859-1", "utf8")
EndFunction

/*
**	EditorDone
**
**	Finish up requester
*/
Function p_EditorDone()
	moai.DoMethod("req", "EndModal", 0)
EndFunction

/*
**	Global Event Handler
*/
Function p_ProcessGUI(message)
	Switch message.action
        Case "RapaGUI":
            If message.attribute="Pressed"
                Switch(message.id) FallThrough
                    Case "call":
                        p_Editor()
                        Break
                    Case "ok":
                        p_CopyBack()
                    Case "cancel":
                        p_EditorDone()
                    Default:
                        Break
                EndSwitch
            EndIf
            ModalUserData=Nil
	EndSwitch
EndFunction

moai.CreateApp([[<?xml version="1.0" encoding="iso-8859-1"?>
<application id="RapaEdit">
    <window id="win">
        <vgroup>
            <button id="call">call dialog</button>
        </vgroup>
    </window>
</application>
]])

InstallEventHandler({RapaGUI=p_ProcessGUI})

Repeat
    WaitEvent
Forever

It's not quite minimized but pressing the button and hitting OK on the dialog box 4 times on my Linux box (Manjaro, x86_64, 16 GB RAM) produced the following results:

(Interpreter:2362): GLib-GObject-WARNING **: 13:51:36.287: invalid (NULL) pointer instance

(Interpreter:2362): GLib-GObject-CRITICAL **: 13:51:36.287: g_signal_handler_disconnect: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(Interpreter:2362): Gtk-CRITICAL **: 13:51:36.287: IA__gtk_window_set_modal: assertion 'GTK_IS_WINDOW (window)' failed

(Interpreter:2362): GLib-GObject-WARNING **: 13:51:47.955: invalid (NULL) pointer instance

(Interpreter:2362): GLib-GObject-CRITICAL **: 13:51:47.955: g_signal_handler_disconnect: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(Interpreter:2362): Gtk-CRITICAL **: 13:51:47.955: IA__gtk_window_set_modal: assertion 'GTK_IS_WINDOW (window)' failed

(Interpreter:2362): GLib-GObject-WARNING **: 13:52:02.724: invalid (NULL) pointer instance

(Interpreter:2362): GLib-GObject-CRITICAL **: 13:52:02.724: g_signal_handler_disconnect: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(Interpreter:2362): Gtk-CRITICAL **: 13:52:02.724: IA__gtk_window_set_modal: assertion 'GTK_IS_WINDOW (window)' failed

(Interpreter:2362): GLib-GObject-WARNING **: 13:52:10.112: invalid (NULL) pointer instance

(Interpreter:2362): GLib-GObject-CRITICAL **: 13:52:10.112: g_signal_handler_disconnect: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(Interpreter:2362): Gtk-CRITICAL **: 13:52:10.112: IA__gtk_window_set_modal: assertion 'GTK_IS_WINDOW (window)' failed

(Interpreter:2362): GLib-GObject-WARNING **: 13:52:18.006: invalid (NULL) pointer instance
malloc(): mismatching next->prev_size (unsorted)
Aborted (core dumped)

I think the culprit is not related to UserData any more. I have eliminated the use of UserData in this minimized code. I'll try to minimize the test farther.

[SamuraiCrow]

Code: Select all

/*
**	Global Event Handler
*/
Function p_ProcessGUI(message)
	Switch message.action
        Case "RapaGUI":
            If message.attribute="Pressed"
                Switch(message.id) FallThrough
                    Case "call":
                        p_Editor()
                        Break
                    Case "ok":
                        p_CopyBack()
                    Case "cancel":
                        p_EditorDone()
                        ;<- Here's where it goes
                    Default:
                        Break
                EndSwitch
            EndIf
            ModalUserData=Nil ;<- This line of code needs to move
	EndSwitch
EndFunction

I found a bug in my code but it still shouldn't coredump ever. The tester seems to be working but my main program it's derived from still coredumps.

Update: If you click OK enough times, the tester still coredumps. I've placed GCInfo() results in a debug print after the EndSwitch in the event handler and passed a 0 to CollectGarbage() before installing the event handler. The count goes up and the threshold remains constant indicating a memory leak somewhere in the Dialog box code.

[SamuraiCrow]

Code: Select all

@REQUIRE "RapaGUI.hwp"

Function p_ProcessGUI(message)
	Switch message.action
        Case "RapaGUI":
            If message.attribute="Pressed"
                Switch(message.id) FallThrough
                    Case "call":
                        Global ModalUserData=data
                        moai.CreateDialog([[<?xml version="1.0" encoding="iso-8859-1"?>
                            <dialog id="req" title="Application">
                                <hgroup>
                                    <button id="ok">OK</button>
                                </hgroup>
                            </dialog>
                        ]], "win")
                        moai.DoMethod("req", "ShowModal")
                        Break
                    Case "ok":
                        moai.DoMethod("req", "EndModal", 0)
                    Default:
                        Break
                EndSwitch
            EndIf
    EndSwitch
    Local c,t=GCInfo()
    DebugPrint("count="..StrStr(c).." threshold="..StrStr(t))
EndFunction

moai.CreateApp([[<?xml version="1.0" encoding="iso-8859-1"?>
<application id="RapaEdit">
    <window id="win">
        <vgroup>
            <button id="call">call dialog</button>
        </vgroup>
    </window>
</application>
]])
CollectGarbage(0)
InstallEventHandler({RapaGUI=p_ProcessGUI})

Repeat
    WaitEvent
Forever

Here is the completely minimal code needed to recreate the coredump. The cancel button, string gadget and variables have been removed. Also, the subroutines have all been inlined and comments removed.

[airsoftsoftwair]

Doesn't crash here with RapaGUI 2.0 so I guess this is fixed already. Keep in mind that dialogs on GTK are rather unstable with RapaGUI 1.2... I think there have been reports about this on here before. But with RapaGUI 2.0 those problems will hopefully be gone.