The uom system leaves some things to be desired. uom’s should be much more interchangeable. I am trying to sell things by the pound and ship them by each. but first my shipping guys have to get a calculator out and a sheet that gives them the pound per square foot. then calculate the square foot. then multiply the two together then multiply by the number of sheets to ship. we cant use a scale for this process, because we sell things in theoretical weight. This really slows the shipping process.
I have a WIP that I came up with today. calculator.js (2.5 KB)
It allows you to set 4 different widgets, and an SQL statement. this helps us some. so any screen we want to convert from uom A to uom B and put the result into a box, all that is needed is 1 line edit and 2 combo boxes. I used it already as such
init(_convertInput, // LineEdit that I put the input into
_convertFrom, // XcomboBox for the From uom dropdown
_convertTo, // XcomboBox for the To uom dropdown
_qtyEdit, // The line edit that I want the output to go to.
"SELECT item_id AS result FROM coitem JOIN itemsite ON(itemsite_id = coitem_itemsite_id) "
+ "JOIN item ON (item_id = itemsite_item_id) WHERE coitem_id = <? value('keyid')?>");
//the sql statment can be null if your passing an item ID to the newId() method shown later
Then later on I select items from an xtree widget. and I connect the newId signal to the newId slot in calculator
_results.newId.connect(newId)
For my case the _results XTreeWidget has id’s for coitem_id. so my coitem_id replaces <? value('keyid')?> above.
Now the only hard part is making the query to get the item id and placing the 3 custom buttons into the desired screens.
One thing that may be possible is to use the same line edit
50 is the input
ea is the uom from
ls is the uom to
55.85 is the output field.
the combo boxes populate automatically with the script