SolidWorks API Nedir? COM Nesne Modeline Uygulamalı Giriş

COM (Component Object Model), Windows'un uygulamalar arası nesne paylaşım standardıdır. SolidWorks, yeteneklerini COM arayüzleri olarak dışarı açar. Pratikte bunun üç somut karşılığı var.

Birincisi: dil bağımsızlığı. COM arayüzü bir sözleşmedir — hangi metodun hangi parametreleri aldığı, dilden bağımsız olarak tanımlıdır. Bu yüzden ModelDoc2 nesnesine VBA'dan da, C#'tan da, C++'tan da, Python'un COM köprüsünden de aynı biçimde erişilir. Metot adları değişmez; yalnızca yazım biçimi (syntax) değişir. VBA'da öğrendiğiniz bir çağrı, C#'a neredeyse birebir taşınır.

İkincisi: nesne ömrü sizin sorumluluğunuzdadır. COM nesneleri referans sayımıyla yaşar. Bir nesneye tutunup bırakmazsanız SolidWorks kapanmayabilir; erken bıraktığınızda ise beklenmedik hatalar alırsınız. .NET tarafında bu, otomasyon kodunun en sık gözden kaçan ayrıntısıdır.

Üçüncüsü: erken ve geç bağlama farkı. Erken bağlama (early binding), SolidWorks'ün tip kütüphanesine (type library) derleme zamanında referans verilmesidir. C#'ta SolidWorks.Interop.sldworks.dll referansı eklediğinizde, VBA'da Tools → References ile SOLIDWORKS type library işaretlediğinizde erken bağlama kullanırsınız. Kazancı büyüktür: IntelliSense çalışır, yanlış yazılmış metot adı derlemede yakalanır, çağrılar daha hızlıdır.

Geç bağlama (late binding) ise nesnenin tipini çalışma anında çözer — Python'daki Dispatch("SldWorks.Application") çağrısı budur. Esnektir, referans kurulumu gerektirmez, farklı SolidWorks sürümleriyle daha toleranslı çalışır. Bedeli, yazım hatalarının ancak çalışma anında ortaya çıkması ve IntelliSense'in olmamasıdır. Python tarafındaki pratik sonuçlarını Python ile SolidWorks otomasyonu yazısında örneklerle gösterdim.

Nesne modeli bir ağaçtır ve her şey kökten başlar. Aşağıdaki şema, günlük otomasyon işlerinin yüzde doksanının geçtiği yolu gösteriyor:

Zinciri şöyle okuyun: oturumdan belgeye, belgeden tasarım ağacına, ağaçtan tek tek özelliklere ve ölçülere. Her basamak bir alt basamağı verir; hiçbir basamağı atlayamazsınız. Otomasyon yazarken kaybolduğunuz anların çoğu, aslında bu zincirde bir basamağı atlamaya çalışmaktan çıkar.

Her düğümün ne işe yaradığı tek cümleyle:

• `SldWorks` — SolidWorks uygulamasının kendisi. Belge açma, kapatma, yeni belge oluşturma ve uygulama ayarları buradan yönetilir. Her kod bu nesneyi elde ederek başlar.
• `ModelDoc2` — açık bir belge. Parça, montaj ve teknik resmin ortak davranışlarını taşır: kaydetme, yeniden oluşturma (rebuild), görünüm işlemleri, feature ağacına erişim.
• `PartDoc` — belge parça olduğunda ulaşılan, parçaya özgü arayüz; katı gövde işlemleri ve malzeme ataması gibi konular burada.
• `AssemblyDoc` — montaja özgü arayüz; bileşenler, mate'ler ve montaj düzeyi işlemler.
• `DrawingDoc` — teknik resme özgü arayüz; sayfalar, görünüşler ve resim düzeyi işlemler.
• `Feature` — tasarım ağacındaki tek bir öğe. Adı, tipi ve alt öğeleri buradan okunur; ağaçta gezinme bu nesne üzerinden yapılır.
• `Configuration` — belgenin bir konfigürasyonu. Varyant üretiminin ve konfigürasyona özel özelliklerin merkezi.
• `Dimension` — bir ölçü. Değerini okumak ve yazmak parametrik otomasyonun en doğrudan yoludur.
• `CustomPropertyManager` — özel özelliklerin okunup yazıldığı yer. ModelDoc2 üzerinden doğrudan değil, ModelDocExtension üzerinden alınır — hiyerarşide en çok kaybolunan nokta budur.
• `SelectionMgr` — kullanıcının o an seçtiği nesnelerin listesi. Kaydedilen makrolarda sürekli karşınıza çıkar; bir sonraki bölümlerde neden dikkatli kullanılması gerektiğine geleceğim.

Bu ağacın okunma biçimi önemli: aşağı inen her ok, "bu nesneyi elde etmek için önce üsttekine sahip olmalısın" demektir. Dimension nesnesine doğrudan ulaşamazsınız; önce uygulamaya, sonra belgeye, sonra feature'a ulaşırsınız.

Her otomasyon kodunun ilk iki satırı aynıdır — uygulamayı yakala, belgeyi al:

Her otomasyon kodu aynı iki hamleyle başlar. Önce kök nesneyi yakalarsınız: çalışan SolidWorks oturumunu temsil eden SldWorks. Sonra bir basamak inip aktif belgeyi alırsınız — ActiveDoc.

Buradaki kritik nokta, ikinci hamlenin boş dönebilmesi. Hiç belge açık değilse elinize hiçbir şey geçmez ve kodun bir sonraki satırı patlar. Bu yüzden her otomasyonun ilk kontrolü şu olmalı: belge geldi mi? Gelmediyse kullanıcıya "açık belge yok" deyip çık.

Belge geldiyse ikinci kontrol türüdür. Belge türü işin geri kalanını belirler: parça mı, montaj mı, teknik resim mi? Parça için yazılmış bir mantığı montaja uygulamak, sahada en sık yapılan hatadır.

ActiveDoc sonucunu kontrol etmeden devam etmek, sahada en sık gördüğüm hatadır. Belge kapalıysa kod sessizce çöker ve kullanıcı "çalışmadı" der.

İkinci basamak, belgeden tasarım ağacına inmektir. Feature ağacı bağlı liste gibi gezilir: ilk feature alınır, ardından sonraki istenir.

İkinci basamak, belgeden tasarım ağacına inmektir. Feature ağacı bir bağlı liste gibi gezilir: belgeden ilk feature'ı istersiniz, sonra her feature'a "bir sonraki kardeşin kim?" diye sorarak zinciri sonuna kadar takip edersiniz. Zincir bittiğinde elinize boş bir sonuç gelir ve döngü orada durur.

Pratik bir ayrıntı: her feature'ın adı, tasarım ağacında gördüğünüz adla birebir aynıdır. Bu, hata ayıklarken en çok işe yarayan bağlantı — koddaki adı ekrandaki ağaçta doğrudan arayabilirsiniz.

Aynı gezinme mantığı montaj bileşenleri, teknik resim görünüşleri ve konfigürasyonlar için de geçerlidir: koleksiyonu iste, sırayla dolaş, aradığını bulunca dur.

Bu on satır, nesne modelinin mantığını özetliyor: elinizde bir nesne varsa, bir alt seviyeye inmenin bir yolu da vardır. Ağaçta gezinmeyi öğrendiğinizde, "şu isimdeki feature'ı bul ve ölçüsünü değiştir" gibi işler mekanik hâle gelir.

Dokümantasyonda aynı şeyin iki adını görürsünüz: ModelDoc2 ve IModelDoc2. Bu bir sürüm farkı değildir.

I öneki COM dünyasında interface demektir; nesnenin sözleşmesini tanımlar. I öneksiz ad ise o arayüzü uygulayan sınıfı (coclass) işaret eder. .NET tarafında SolidWorks interop kütüphanesi her ikisini de sunar ve pratikte ModelDoc2 ile IModelDoc2 birbirinin yerine kullanılabilir; C# kodunda çoğu geliştirici I önekli biçimi tercih eder çünkü sözleşmeye bağlanmak daha nettir.

VBA'da genelde I öneksiz adı yazarsınız. Dokümantasyonda ise başlıklar çoğunlukla I önekli biçimdedir. Aynı sayfaya baktığınızı bilmek, aramada zaman kazandırır — ModelDoc2 bulamadığınızda IModelDoc2 aratın.

Nesne modelini öğrenmenin en hızlı yolu dokümantasyonu baştan okumak değildir. Sıra şudur:

1. İşi elle yaparken kaydedin. Macro Recorder'ı açın, otomatikleştirmek istediğiniz işlemi normal şekilde yapın, kaydı durdurun.

2. Üretilen kodda hangi arayüzün çağrıldığına bakın. Kaydedilen kod üretime hazır değildir — seçime ve ekran durumuna bağımlı çıkar. Ama size aradığınız bilgiyi verir: bu iş hangi nesnenin hangi metodu üzerinden yapılıyor.

3. O arayüzü API Help'te aratın. Artık aradığınız şeyin adını biliyorsunuz. Dokümantasyonda o metodun tam imzasını, parametrelerin anlamını ve varsa alternatiflerini okursunuz.

4. Kodu seçimden bağımsız hâle getirin. Kaydedilen kod "ekranda seçili olanı" işler. Üretim kodu "adıyla bulduğunu" işlemelidir.

Bu sıranın kazandırdığı şey şu: dokümantasyonda arama yapabilmek için önce ne arayacağınızı bilmeniz gerekir. Macro Recorder tam olarak bunu söyler. Yapay zeka araçları da bu keşif aşamasında hızlandırıcıdır, ancak COM yaşam döngüsü ve sürüme özgü davranışlarda kendinden emin biçimde yanılabilirler; sınırlarını yapay zeka ile SolidWorks eklentisi yazarken ayrıca ele aldım.

Kaydedilen her makro SelectionMgr üzerinden çalışır, çünkü Macro Recorder sizin tıklamalarınızı kaydeder. Kod şuna benzer:

Kaydedilen her makro seçim yöneticisi (SelectionMgr) üzerinden çalışır, çünkü kaydedici sizin ekranda yaptığınız tıklamaları kaydeder. Bu yol iki şeyi varsayar: kullanıcının doğru şeyi seçmiş olduğunu ve seçimin hâlâ geçerli olduğunu.

Seçimi gerçekten kullanmanız gerekiyorsa — örneğin makro, kullanıcının o an işaretlediği nesne üzerinde çalışacaksa — kural şudur: seçimi varsayma, oku ve doğrula. Önce kaç nesne seçili olduğunu sorun; sıfırsa iş orada biter ve kullanıcıya söylenir. Sonra seçilen nesnenin beklediğiniz türde olup olmadığını kontrol edin.

Bir de klasik tuzak var: SolidWorks'ün seçim koleksiyonlarında dizin 1'den başlar, sıfırdan değil. Sıfırıncı elemanı istemek, COM tarafında en sık düşülen hatalardan biri.

Seçime hiç bağlı olmayan yol ise her zaman daha sağlamdır: nesneyi belgeden doğrudan isteyin. O zaman makro, kullanıcının ekranda ne yaptığından bağımsız çalışır.

Bu kod çalışır, ama üç sebeple kırılgandır:

• Ekran durumuna bağımlıdır. Kullanıcı yanlış şeyi seçtiyse, hiçbir şey seçmediyse veya seçim sırası değiştiyse davranış değişir.
• Toplu işlemde kullanılamaz. Yüz dosyayı arka arkaya işleyen bir akışta "seçili nesne" diye bir şey yoktur.
• Sessizce yanlış çalışabilir. Yanlış nesne seçiliyken kod hata vermez; yanlış nesneyi işler. Bu, hata vermekten daha kötüdür.

Sağlam yaklaşım, nesneye kimliğiyle ulaşmaktır: feature'ı adıyla bulmak, konfigürasyonu adıyla almak, özel özelliği anahtarıyla okumak. Seçim yalnızca kullanıcının bilinçli olarak bir şey işaret ettiği etkileşimli senaryolarda kullanılmalı; toplu ve arka plan işlerinde hiç kullanılmamalıdır.

SolidWorks API sürümle birlikte gelişir. Yeni arayüzler eklenir, mevcut metotların yeni numaralı sürümleri çıkar — Save3, GetSelectedObject6, Add3 gibi sondaki rakamlar tam olarak bunun izidir. Eski sürümler genelde çalışmaya devam eder, ancak yeni yetenekler yalnızca yeni arayüzlerde bulunur.

Üç pratik kural:

• Hedef sürümün dokümantasyonuna bakın. API Help sürüm sürüm yayınlanır. 2021 kurulumu için 2025 dokümantasyonuna bakmak, olmayan bir metodu aramanıza yol açar.
• En düşük ortak sürümü belirleyin. Kodunuz beş kişinin makinesinde çalışacaksa, aralarındaki en eski SolidWorks sürümü hedefinizdir.
• Numaralı metotlarda en yüksek desteklenen sürümü seçin. Aynı işi yapan Save ve Save3 varsa, hedef sürümünüzün desteklediği en yenisi genelde daha fazla kontrol sunar.

API'nin kendisi ayrı bir ürün olarak satılmaz; SolidWorks lisansının parçasıdır. Ancak erişebildiğiniz yetenekler kullandığınız sürüme ve lisans seviyesine göre değişir.

Sıralamayı önemsiyorum, çünkü çoğu kişi üçüncü adımdan başlayıp tıkanıyor:

1. Macro Recorder ile keşif. Beş farklı işi kaydedin ve üretilen kodu okuyun. Amaç kod yazmak değil, hangi işin hangi arayüze düştüğünü görmek.

2. Kökten belgeye zinciri ezberleyin. SldWorks → ModelDoc2 → belge türü dalı. Bu üç basamağı düşünmeden yazabilir hâle geldiğinizde, geri kalanı keşif işidir.

3. Kaydedilen bir makroyu seçimden kurtarın. Elinizdeki kaydı alın, SelectionMgr bağımlılığını sökün, nesneleri adıyla bulun. Nesne modelini gerçekten burada öğrenirsiniz.

4. Özel özellikler ve konfigürasyonlarla çalışın. CustomPropertyManager ve Configuration, geometri riski olmadan gerçek değer üreten alanlardır. Toplu özellik doldurma, ilk üretim otomasyonunuz için iyi bir adaydır.

5. Ölçü ve feature değiştirmeye geçin. Geometriye dokunmak en son adımdır, çünkü hata maliyeti en yüksek burasıdır. Parametrik bir modeli koddan sürmek, bu beş adımın toplamıdır.

Bu sıranın uygulanmış hâlini ParametriX projesinde görebilirsiniz: parametrik model kurallarıyla API otomasyonunun birleştiği yer tam olarak beşinci adımdır.

SolidWorks API nedir, kısaca? SOLIDWORKS için bir COM programlama arayüzüdür. VB, VBA, VB.NET, C++, C# veya makro dosyalarından çağrılabilen yüzlerce fonksiyon içerir ve SolidWorks'ün nesne modeline dışarıdan erişim sağlar.

`ModelDoc2` nedir, neden her yerde geçiyor? Açık bir belgeyi temsil eden arayüzdür. Parça, montaj ve teknik resmin ortak davranışları burada toplandığı için hemen her otomasyon kodu bu nesneden geçer.

`IModelDoc2` ile `ModelDoc2` arasındaki fark ne? I öneki COM arayüzünü, öneksiz ad ise onu uygulayan sınıfı gösterir. Pratikte aynı yeteneklere erişirsiniz; dokümantasyonda arama yaparken her iki biçimi de deneyin.

API'yi öğrenmeye nereden başlamalıyım? Macro Recorder'dan. Bir işi kaydedip üretilen kodda hangi arayüzün çağrıldığına bakmak, dokümantasyonu baştan okumaktan çok daha hızlı ilerletir. Hangi uygulama biçimiyle (makro, eklenti, bağımsız uygulama) çalışacağınıza ise makro ve API rehberindeki karar modeliyle bakabilirsiniz.

Hangi dili seçmeliyim? Nesne modeli her dilde aynı olduğu için ilk aşamada dil ikincil bir karardır. VBA en hızlı başlangıcı verir, C#/.NET kalıcı çözümlerde tercih edilir, Python hızlı prototipleme için elverişlidir — COM üzerinden API'ye nasıl bağlanacağınızı SolidWorks Python otomasyonu yazısında adım adım anlattım.

API ücretli mi, ayrıca satın alınıyor mu? API, SolidWorks lisansının parçasıdır; ayrı bir ürün olarak satılmaz. Erişilebilen yetenekler kullandığınız sürüme göre değişir.

Kaydedilen makro neden üretimde bozuluyor? Çünkü kaydedilen kod seçime ve ekran durumuna bağımlıdır. SelectionMgr bağımlılığı sökülüp nesneler adıyla bulunmadıkça, kod ilk farklı senaryoda ya durur ya da yanlış nesneyi işler.

SolidWorks API'yi öğrenmek, metot listesi ezberlemek değil, bir haritayı içselleştirmektir. SldWorks → ModelDoc2 → belge türü → Feature / Configuration / CustomPropertyManager zincirini düşünmeden yazabildiğinizde, bilmediğiniz her iş yalnızca bir arama sorusuna dönüşür.

Pratik özet:

• Her şey kökten başlar; ara basamağı atlayamazsınız
• COM sayesinde nesne modeli dilden bağımsızdır — öğrendiğiniz bilgi taşınır
• Erken bağlama öğrenirken IntelliSense verir, geç bağlama esneklik verir
• Bir işi bulmanın en hızlı yolu Macro Recorder → üretilen kod → API Help sırasıdır
• Seçim tabanlı kod kırılgandır; nesneye kimliğiyle ulaşın
• Hedeflediğiniz SolidWorks sürümünün dokümantasyonuna bakın

Firmanızda tekrar eden SolidWorks adımlarını koda taşımayı düşünüyor ve nereden başlayacağınıza karar veremiyorsanız, süreci birlikte değerlendirebiliriz — iletişim bölümünden yazabilirsiniz.