[SDK] Paramblock messages


#1

Anytime a paramblock value is changed, the paramblock sends notifications with PART_ALL as the part.

Anyway to customize which part(s) will be sent for a particular parameter? Ie, can I tell it to just send PART_DISPLAY or PART_MTL etc for certain parameters?


#2

you could send that message yourself in a PBAccessor for that Parameter when it’s changed


#3

If I do that, can I block the default message?


#4

you can enable and disable notifications with

IParamBlock2::EnableNotifications(BOOL onOff)

though it’s a “global” switch for params in the block, so you might need to process all param messaging for the block.


#5

Hmm yea but that’s a global switch for all param blocks…


#6

sorry yes, all param blocks, I assumed it was just all params in the block :confused:


#7

Can you explain in more detail why you need to specify notification messages? Maybe there are some alternative solutions…


#8

It’s not an XY problem. If there’s no way for me to flag certain params as changing only certain PART ids, then I guess I’m out of luck :slight_smile:


#9

I just think … the specified notification is not a very common option. Most plugins work well without it. So maybe you can do something like IRefTargMonitor to monitor and modify messages the way you want.


#10

is the parameter a reference ?


#11

Here’s a more complete outline of the problem.

When tyFlow gets a REFMSG_CHANGE/PART_ALL from an input object, it resets the cache and recomputes the sim.

Input objects can be all kinds of things, but also various tyFlow-related helpers (tyWind, tyIcon, etc).

Those helpers have aesthetic properties that only affect their viewport display (display icon, icon size, etc).

Currently, if a user disables one of the aesthetic properties, the helper’s pblock will send a notification with REFMSG_CHANGE/PART_ALL, which will be received by tyFlow and the sim will reset. But that behavior is very unnecessary and inefficient, as those aesthetic params shouldn’t cause a cache reset on the flow since they have no effect on the simulation.

So I was hoping to be able to tag those params in the pblock definition with something that would be passed around the message system, so I could later filter out certain params from causing a sim reset.


#12

yeah you can do that :slight_smile:

in your NotifyRefChanged function of the helper

switch(msg)
{
	case REFMSG_CHANGE:

		if(htarg == pblock)
		{
			ParamID lastparam = pblock->LastNotifyParamID();	

			if(lastparam == show_icon_id)
			{
				GetCOREInterface()->ForceCompleteRedraw();  // you need to force redraw or nothing will happen
				return REF_STOP; 
			}

there may well be other/better ways to achieve this result but i’ll have to think about it :slight_smile:


#13

Not sure why that code would go in the helper NotifyRefChanged function…the helper is what’s changing, and it’s tyFlow that receives the message.

And I don’t see how that will work either way…the htarg will be my pblock, yes…but the id will simply be the id of the TYPE_INODE param containing the helper node. It won’t tell me which param of the helper node was changed…unless I’m misunderstanding your approach :slight_smile:


#14

it works I’ve tested it :slight_smile:

the paramblock that’s changing is a reference target to the helper plugin so when the paramblock sends the message to it’s dependents it’s sent to the helper and then it’s sent to it’s dependents your tyflow. So when the helpers NotifyRefChanged recieves the message from it’s paramblock we can stop it in it’s tracks.


#15

What is the helper plugin? I think that extended IRefTargMonitor is enough, and it can override NotifyRefChanged
the same way. The good reference in SDK is RefTargMonitor or NotifyMgr.


#16

Klvnk:

Oh shoot I didn’t think about the fact that the helper Object will receive the message before it’s sent further. Your approach makes sense now. I will give it a shot and report back.


#17

Worked like a charm…thanks a lot!