Hyperion Entertainment Message Boards

I'm fiddling with commodities.library. I'm new to this library I'm still discovering its features.
Now my problem is that I want an independent program to show the GUI of one of my commodity. For this I've understood that I can create another CxBroker with the same internal name and be sure that my running cxBroker has NBU_UNIQUE set and the new one NBU_NOTIFY. That's ok and it works great.

Now my problem is that my running cxBroker can have different names depending on the associated hardware (this way in Exchange it appears with the hardware name, rather than with a generic name). Nothing in the autodocs, but in the interface I spotted a CopyBrokerList() method which is not described in the autodocs. It does exactly what I was looking for (at least it seems to), except that I don't know the node structure it's returning.
So for now I'm just using the node name and then try to create a CxBroker with that name. It works but I'm almost sure CopyBrokerList does not return a plain struct Node but an extended structure in which I would find a way (MsgPort ?) to directly send a CXCMD_APPEAR without trying to recreate a broker with the same name. Would be cool if CopyBrokerList() was documented in the autodocs.

In the end what I was looking for (which does not seem to exist) is a way to find a commodity by it's internal name and then be able to send to this broker some messages through its message port. If this is considered as hazardous a ControlBroker(CONST_STRPTR brokerName, uint32 cxCmd) would do the job keeping internals of commodities.library private and at the same time allowing to send one of CXCMD_XXXXX command to an existing broker identified by its name.

Each node in the list is a private structure, so you'll have to treat it as a struct Node. The private extended fields of the node are of no use to the application programmer anyway.

Simon

@abalaban
I don't see any broker message ports in Ranger so it's possible that they are meant to be private communication channels but I can suggest an alternative. Can you add a second message port to your broker, give it the same name as your broker, add it to the public port list ( AddPort() ) and find the port ( FindPort() ) in your external program using the name you found in the in the broker list? Your broker would just need to Wait() on signals from both ports and you would know by the signal you receive if the message is from Commodities or from your external program.

@Rigo

I feared that answer So is it considered safe to use that CopyBrokerList() method?

@xenic

Thank you for your suggestion the idea was to use existing material not to add new lines of code to do something that already exists. All I want to do is to send my commodity the standard Commodity command to show its GUI. All the difficulty is that my commodity hasn't a fixed name (because probably to save some memory original authors chose to use "internal name" to display in Exchange list) but adapt its name to the controlled hardware. The possible name list is known so I have to loop on them and see if there is a commodity running for each.

abalaban wrote:Thank you for your suggestion the idea was to use existing material not to add new lines of code to do something that already exists. All I want to do is to send my commodity the standard Commodity command to show its GUI. All the difficulty is that my commodity hasn't a fixed name (because probably to save some memory original authors chose to use "internal name" to display in Exchange list) but adapt its name to the controlled hardware. The possible name list is known so I have to loop on them and see if there is a commodity running for each.

Is there any reason why you need to have a different short name? Can't you put the hardware type in cx_Title?

@Chris

In Exchange, title is only shown on the right side when you select the commodity in the list. So in case someone has several supported hardware installed it will have several instances of the commodity, having the same name for all of them is not very user friendly, the solution was to adapt the name to the driven hardware.