An access violation can occur any time an invalid memory operation occurs, I'm not sure I've seen any particular pattern, but JMP seems incredibly robust to table operations so that's probably the last place I would look. The problem of course if its hard and tedious to diagnose the location of the problem. I usually place a Throw() in my code to try and abort execution before the crash occurs. Then by moving the position of the Throw I can home-in on the area of code that is causing the problem. Sometimes I have done something clearly stupid, other times it might be a couple of mistakes which in combination are catastrophic.
Here is an example. A modal window is created with a handler for the validate event - the handler returns 1 or 0 indicating whether or not the window should close when OK is clicked:
New Window("Test", <<Modal,
<< On Validate(
txt = Trim(teb << Get Text);
If (Length(txt) > 0,
isValid = 1
,
isValid = 0
);
// return
isValid
),
Lineup Box(NCol(1), Spacing(10),
Text Box("Enter something, anything, but something:"),
teb = Text Edit Box("")
)
)
This works fine, you can run it without crashing JMP! When we write a function or an event handler then the last thing evaluated is what gets returned (see Glue to understand why). But at some point JMP introduced a Return function which makes "returning" more explicit - it works with functions but not event handlers like above. So replacing isValid with Return(isValid) in the last line of the OnValidate will not work. But JMP won't crash. But if I were to mistakenly use the OnClose event then JMP gets unhappy and will give me an access violation:
// dont try this at home
New Window("Test", <<Modal,
<< On Close(
txt = Trim(teb << Get Text);
If (Length(txt) > 0,
isValid = 1
,
isValid = 0
);
Return(isValid)
),
Lineup Box(NCol(1), Spacing(10),
Text Box("Enter something, anything, but something:"),
teb = Text Edit Box("")
)
)
-Dave
