[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!