Link between my CXOB orders CXOS line

One of my more time consuming tasks is managing my open CX orders. Like most that have been playing, I have a very long list of open orders. If I need to find a given order for a material at a given CX, I have to scroll through the creation time sorted CXOS list to find the specific order, usually for the purposes of deleting it.

When I check the CXOB orders list for a commodity that I already have an open buy or sell on, I often want to cancel that old order and replace it with a new one at a different price. So off to the long CXOS list where I manually scan it, find the old order and delete, then create the new order.

What I’d like to see is some feature that allows single click linkage between my CXOB orders and the ability to manage that order. That could be done by making my order in the CXOB clickable with the action that pops open a dedicated CXOS for just that order, or by adding a small Delete button on the line item in the CXOB window, which would solve 90% of the use cases.

An alternate approach could be to allow inline editing of the quantity and price in the CXOB, though I don’t know if the UI currently supports that concept anywhere else. I suppose an alternative could be to pop up a new Trade window pre-populated with that quantity and price and then change the action to Replace, which would remove the old and create a new with any updated values.

1 Like

Yeah editing of orders is pretty standard across every real-world trading application. Nowhere has you cancel and replace it manually.

It’s a pretty simple implementation - only two fields will ever need to be modified.



Genuine order editing has too many edge cases to implement, and isn’t worth it.

However, some kind of “quick replace” function would be okay. Basically a shortcut for deleting an order and then adding a new one on the same order book.

This could be done with a dropdown in the CXPO buffer which allows you to select one of your existing orders to replace. This would also be handy because you could use it to see your existing orders on that order book at a glance.

Then the CXOS view would have an additional REPLACE button, next to DELETE and VIEW, which would open CXPO with that order already selected.

1 Like

Yeah the industry term is “atomic replace” and happens within the matching engine. The problem it solves is a “delete, modify, replace” function can cause an order to be double-executed in rare situations of the existing order is executed in the time the user sends the command from their web interface to the website (50-250ms). And if fault detection isn’t present, can be common. Atomic replace causes order editing to happen within the matching engine itself, which is sequential, which means these faults can’t happen as execution and replacement of orders are serial operations and cannot be double-counted.

This is an important distinction to understand when thinking about how to execute an automated order replacement. Race conditions are rare, but they can and do happen. I’ve personally had this happen in my trading career, multiple times. And then several seconds later I realize my exposure is a multiple larger than I expected after both orders ended up getting filled. That’s never fun.

This is how it functionally works at the coding level - at the user web interface level, it’s transparent to the user. How the “edit” functionality actually is coded within the web interface does not matter. Whether it’s a seperate window or each transaction has a little “edit” button to edit them in-line. That user interface makes no difference. All the functionality which actually matters in how it’s handled in the backend.

I suggested the format because that is the industry default for how to handle modifying existing orders. Across every broker\exchange\platform, you have a list of exiting limit orders and you have some way to edit them in-line. You do not need to bring up a separate buffer or window.

See another example:

And another example:

EDIT: I actually can’t show a screenshot of this one - but trust me I have another platform’s implementation example

Handling serial transactions in a guaranteed way isn’t rocket science, at least if using an ACID based DB. Just have the client wait on confirmation of delete prior to executing the update (though it’s a new order under the covers). It can definitely be tricky if using an eventual consistency model, though that is probably serious overkill for something as low scale as transactions must be on PrUN.

I like your suggestion, but when looking at how PrUN implemented their UI components, I don’t see the notions of dropdowns or inline editing. The pattern is either an embedded button or to pop up a new CMD window specific to that action that has input fields. So I’m usually thinking easiest to implement without having to introduce new concepts.

There’s already two pieces of functionality to leverage here. There’s a CXO {orderid} screen and the ability to link from within one CMD screen to another with a predefined command. For instance, in the CXOB screen for each order I can link to the individual player screen (CO {corp}). So I see the easiest suggestion would be:

  • Modify the CXO screen to include a DELETE button. That would use the existing functionality for DELETE from the CXOS screen, so should be straightforward
  • Create a link from any order in a CXOB where the Trader == viewer to the appropriate CXO order popup

With those two changes I can directly access my specific orders for that commodity on that exchange. No more scrolling CXOS to find it. Then I would manually delete from there. If I then wanted to change the order I’m already at the order book to start the trade. It’s simple changes to implement a simple quality of life type of feature.

One issue with the suggestion to have the CXO buffer contain a DELETE button is - what should the CXO buffer display after the user clicks DELETE? Currently, if you have CXO open and then click DELETE in the CXOS view, the CXO switches to this:


But it doesn’t make sense for CXO to show that after you click a button in the CXO itself - it will seem like something went wrong. We’ll start getting bug reports of “I tried to delete an order and got an error”.

The CXO could close itself, but I don’t think there is an example in the existing UI of a buffer that closes itself, so that would be disconcerting. As far as I can see, there isn’t a way to handle this well using the existing UI paradigms.

This is a good point. It’s the fly in the ointment of my least work suggestion.

When I think about it, should orders ever be DELETEd? Any trade app that I’ve ever used allows orders to be cancelled but never fully removed from the transaction history.

So my new suggestion is to change the approach for CX deletion to CANCEL. The cancelled order stays in the history and can be access with a state of Cancelled. It could actually be useful for both player and dev troubleshooting to figure out where an order went. You could easily track cancellation time and what action triggered it.

With this implemented the above problem goes away for all cases. Not only the inline order cancel, which then would serve as a cancellation confirmation, but also the case where you have the order opened in a CXO and then delete it from the CXOS. Clean solution.

So there are multiple tiers of this.

Currently APEX has active orders only. Active and “filled” I guess. But once removed, there is no history. The current implementation of this is perfectly fine.

The next level is a “fills” page which has a ledger of all filled orders. So you can go back and view your sales and purchases that have executed at the order level. I think this is a reasonable addition for actual utility.

The next level is a “transaction page”, which will show a history of everything. Including canceled orders, and if an order was filled by multiple parties, each is a line item. This is probably excessive for PRUN.

There’s a significant difference between what is stored in the DB verses what has a dedicated UX. A single table can very easily track all states: active, partially filled, completed, cancelled

Dedicated views are probably overkill as well. All that is needed is filtered views with a single implementation. CXOS right now gives the entire table, with a row for state – currently showing the first three states above. Add the fourth (should be trivial if it’s just a state field in the DB) and then filtering would be a fantastic QoL addition, as would at least sorting. Not just state either. I’d love to be able to filter and/or sort by exchange, commodity, order type.

If the extra state is tracked in the same DB, then the tx not found issue that was pointed out above is no longer a problem. There is still a tx and it’s state is cancelled. No UI mods needed.

1 Like