Abstracting DropMany in VB.NET beginner question

[Visisthebest]

For using DropMany from a VB.NET VSTO add-in, I would like to create some abstraction for the way I use it and guard against errors this way.

Because I am a VB.NET beginner some advice if this is an ok way to go is appreciated!

This is the why of it:

1. I have some code that builds a 500+ diagram, can also be 3000+ diagrams (with 2-3 subshapes + connections means 10.000+ shapes/connectors dropped, hence the why of DropMany, much faster across the .NET interop)
2. I want to collect the shape drops in a 'ToDo list', using a VB.NET List, which is then processed by a function that converts the list and calls DropMany.
3. I always use a Stencil master as the object to drop, so I hide the other options DropMany offers.
4. It is just much easier to pass around a VB.NET list and add things to it than a regular array that DropMany requires.

To store the data in a list item, I use a very simple object:
Public Class ShapeDropToDoItem
    Public MasterToDrop As Visio.Master
    Public X As Double
    Public Y As Double
End Class

A structure would work too, but has some undesirable behavior in a VB.NET List. This is just to store data in an item, no abstraction in the object.

DropMany returns an VBA Int16 array with the new Shape IDs, my function converts it to a Int32 array for internal consistency.

Is this an ok way to go?

I want to use a similar concept for abstracting GetResults and SetResults. In that case, I check if any of the Shape IDs is too large to be stored in Int16 (let's say shape ID 70000), in which case I use Cell.Result and loop through the respective GetResults/SetResults VB.NET todo list and read/write the cells one by one.

This is an unlikely edge case, but we tried the huge diagrams on a new AMD Ryzen desktop with 64 bits Visio and noticed just how much better/faster it works with huge diagrams. That edge case may be closer than we think.

(Don't forget that if users do a lot of editing on a large diagram, deleting copy/pasting etc, the ID counter may keep running higher and higher even though there are not so many shapes on the diagram as the highest ID seems to indicate.)

Your feedback on the above much appreciated!