To develop a good solution to what you described, besides the good understanding of the business process (how the object data is used, organized...), the skill and knowledge of AutoCAD programming (.NET APIs, mainly) and MS .NET framework (regardless of using C# or VB.NET) would decide the quality/usability of your application.
Your solution should be structured in multipe tiers(layers), and each focuses on specific works:
1. OD table defining/configuring. This should be mostly non-coding task. You can define your OD table in text/csv file, XML file, or even better in a database in intranet network, or even somewhere in the cloud). You need to be aware that eventaully the OD table definition data (text file, or database tables) should be managed by business leader (CAD manager, for example), not programmer. So, they should not have to look at the data and try to figure it out what does it mean in term of definition an Object Data table. Thus, there may be need to have a seperate app to provide easy-to-follow UI for business leader to configure custom object data tables/fields... Mind you, this UI/app in general is not meant for every CAD users who deal with Object Data in drawing.
2. The you should organize all the code that access OD table configurations, manipulating OD data in drawing into another tier, which covers all business logics that deal with Object Data, such as in which cases specific OD tables are needed to be created, validated, removed from a drawing, targeting certain types of entities to attach/detach OD records, searcing/querying OD ata in drawing...
3. The UI tier shown in AutoCAd for user to deal with OD table/data.
Using PaletteSet/modeless dialog is required rather advanced AutoCAD .NET knowledge if the data shown UI is "per document" based (in your case, showing custom OD data is very likely "per document" based): because the currently active document ccan change while the UI is visible, thus the data shown there must be syched with the activate document change. There are different ways to may the modeless UI to interact with data from drawing, but I found that when working with PaletteSet, using WPF with MVVM patterns would be much better approach.
As per your pointed questions:
1. The best way to bring data table (definition/configuration) from backend (be text/CSV file, or database), would be define a data acccess Interface, so that the code in AUtoCAD side only deals with the Interface object witjout having to know how/where the data is from. I am not sure if you know the concept of separating one process from other with Interface. With Interface sits between AutoCAD app and your OD table definition data, whatever you do to the OD definition data (being each table a file, or one file covers all OD tables, or using XML. or using database), it would not affect the code on AutoCAD.
2. The cod for accessing OD data in drawing should in different tiers as the code for UI. Do not mix them together, such as in your button click event handler:
you do not do:
private void MyButton_Click(...)
{
''Go to MdiActiveDocument
'' Search OD data
'' change OD data, fi necessary
'' Update UI, be it Grid, or not
}
you do
private void MyButton_Click(...)
{
'' Get MdiActiveDrawing
'' A tier2Class.Dosomething(mdiActveDwg)
'' Based on Tier2.Class' execution result, update UI
}
3. Yes, of course you can use dropdown/combobox to show available OD Table (name, fields, data type, value range...) Again, you do not reach the OD table definition directly from UI. Use middle tier class to access OD table definition data, and return them back to UI.
One more thing, while Object Data has been around for quite a while, I found Autodesk managed to make bad things happen to it from versions to versions, oftern something got broken in this version and fixed in aother, and new break somehow introduced, and so one. I have being using Civil3D2015 in past 3 years, and ran into some bad things on OD Data side that do not exist in AutoCAD Map 2015, nor in Civil2017/2018 (I never tried Civil2016). So, if possible, I'd suggest based on your develop on later Civil3D version than 2015, if possible. I am pretty sure with what you intend to do, it would take a while to get fully worked as expected. By then Civil3D 2015 would be "too" old version.
