How to prevent "invalid" data in a DB field (e.g., via numeric control)

I have a pcclasslevel control (numeric) and the setting of the DB value triggers onValueChanged() which then calls a "calculate level based stuff method"

I also have a max level checking method that checks max allowed level for a class as well as for a race/class combo. If I wanted to hard limit the pclassLevel to the max level for a class (regardless of race) - how do I do that?

I do not want to use the min/max values in xml for this as they are not static. I COULD set them whenever the pcclass field changes and call setMaxValue() on pcclasslevel from there. I believe that would work.

But, ideally, I'd like to have a "reject change" type check. When I have Fighter, Human, 10 and drag Fighter on top of class - it should reject upping it to 11. Currently, I have this. BUT if someone types "11" in the Level field, it takes it. If I add the check to reset to 10 in that onValueChanged for Level, it would be a recursive skip. I do not see a "onAboutToChangeValue" or "onValueSubmitted" method - so I guess I need to do the setMax whenever class is set?

I figure this "validation" issue is common enough many of you have thought about it and done it.

But that means, I just realized - calling a method on the CONTROL instead of a DB.setValue(...) type call. So, now I like it less since my .lua code does not refer to windows/controls currently :(

While looking for ideas (and this won't work since they are all "post-action" callbacks) I saw:

Code:

---

function addHandler(nodepath, event, callback)
Add an event handler callback function to a specified database event on any node matching the specified database path.

The handler function should have the following signature: [function name]([parameters]). The parameters will vary depending on the database event the function is attached to, as follows.

* [onAdd] parameters = (nodeAdded)

* [onCategoryChange] parameters = (nodeChanged)

* [onChildAdded] parameters = (nodeParent, nodeChildAdded)

* [onChildCategoriesChange] parameters = (nodeParent)

* [onChildDeleted] parameters = (nodeParent)

* [onChildUpdate] parameters = (nodeParent, nodeChildUpdated)

* [onDelete] parameters = (nodeToBeDeleted)

* [onIntegrityChange] parameters = (nodeChanged)

* [onUpdate] parameters = (nodeUpdated)

Parameters

nodepath  (string) 

A data base path identifier. The '*' character can be used as a wildcard for a path segment.

event  (string) 

The event to be captured (onUpdate, onAdd, onDelete, onObserverUpdate, onChildAdded, onChildUpdate, onChildDeleted, onIntegrityChange)

callback  (function) 

The function to be called when the event triggers

---

Was curious what onObserverUpdate does? / Used for?

Ah...

onEnter() (thought was on ENTERING the field (that's gainFocus ;P). and onLoseFocus()

So, I will start playing with these to get it so when hit enter it adjusts the value to max based on some other DB data. Then will check what happens if type 11 when 10 is max and don't hit enter but tab - if onEnter never called, then guess I have to validate it 2x. Will look.

(still feel free to comment!)

OK - no idea - time to remove all the comments and retest because it appears to be working AS-IS.

I did not add any handlers to onEnter() or onLeftFocus() - it is working...

From what I see though - if put focus on the number field and type, it reacts to onValueChange PER keypress (which I didn't know and is fine) so changing 10 to 1 (calls changed) 11 calls changed, fails validation and sets it to 10 (calls changed), now all is good and recalls thac0 etc.

Hmmm :)


Still wondering about my question on #3 - what does onObserverUpdate do/for?

https://fantasygroundsunity.atlassia...ObserverUpdate

It's usually used to do any code that's required when the owner of the database node changes.

Search in CoreRPG for "onObserverUpdate" to see examples of how it's used.

Ah cool thanks! I will look at that (I hadn't searched for it in Core or other rulesets since it was just something I saw when looking for ideas on solving the (non)issue I was having.

I didn't see a description on the original Wiki link I usually go to. I would do so because I had thought some of the info in new Attlasian site would mess me up since I was still working under FGC. After this simpler one is done, I plan to do next one under FGU.

I figured, if there are things to take advantage of in FGU - I'd wait until I had the one I had more exposure to under my belt.