I'll probably implement something like this for the phone app version because there's less realestate and like you said it'll be better for dexterity and speed, but in the mean time.. for the PC app, and probably tablets.. I've actually got it working (insert balloons and fireworks)...PointsWell wrote: ↑Tue Jan 31, 2023 2:14 am Just as an aside, there are better alternatives to drag drop, if you've got two grids visible.
Running a process on clicking on the line items requires less dexterity and will be faster.
Grid One - Deliveries available for reschedule
Grid two - Delivery slots that are open.
Place grid one on the left and grid two on the right.
Use a non persisted BO for Session Variables. Create two number fields, one for Delivery To Change and the Other for Open Delivery Slots. These must be set with an initial value of zero (otherwise you'll get errors and it won't work properly)
Create Two processes
Place one process as the default action on grid one. The process should take the BO and put the ID of the BO into SessionVariables.DeliveryToChangeID
Then check to see if SessionVariables.OpenDeliveryID is greater than 0. If it is call the process to make the change to the delivery slot
Place the second process as the default action on grid two. The process should place the BO.ID for the open delivery slot into SessionVariables.OpenSlotID. Then check to see if SessionVariables.DeliveryToChangeID is greater than 0, if it is call the process to make a change to the delivery slot.
The last step in the process should be to redisplay the layout. Don't use grid refresh on process as your grid will loose the highlighted BO and the end user will be confused.
This requires the user to click on two grid lines which is a more accessible solution than clicking dragging and dropping.
I only use IDs in SessionVariables (as opposed to BOs), because of the way that AIM executes the SQL to keep things in context, you obviously have to do the additional FIND to bring the other BO into context.
And apologies for the random copy and paste in my initial message. Feel free to delete it (please).
if anyone is interested in how...
It's not as flexible as far as being able to handle any number of timeslots, but I've settled for up to 10, which is enough for any 1 day and 1 destination at a time. Also, once I'm finished tweaking it, any loads that have been dispatched will fall off the grid, so if there happens to be more than 10, the next 'later' ones will come into view.
So, for the right side query, I used a form, with 10 grids (as in 10 lines) that display a single record each (1 for each slot for that day for that destination (eg. Coles) which are stored in the session object, then I capped the height of each query to the height of one record (so it wouldn't expand when I dropped something on it), and I took out all the scroll bars and navigation etc for each grid.
As for the drop process in each, I've allocated a separate process (eg. DropT1 for Grid 1 on the form, DropT2 etc...), so that I have the data required to update the dragged item from the left query with the timeslot information in the header record.
It sounds like a lot of overhead, but it turned out to be pretty simple and straight forward and since this particular BS/App will be only really getting used by 1 person at a time, maybe 2, on site.. and there aren't really any more than a couple of hundred records to deal with on any particular day in total.. it should satisfy their need for Drag and Drop.
It doesn't even look or feel bodgey... and that's without any formatting or trying to make it pretty. So it should come out alright when I'm done.
Thanks again for the time & input.