Forenbeiträge von System.ComponentModel Ingesamt 6 Beiträge
Die Begründer des Windows APi waren so schlau genau diesen Fall voraus zu sehen. Sofern um es sich um eine native Oberflächenwanwendung handelt sollte das mit PostMessage und SendMesage möglich sein. Darüber hinaus gibt es das DDE System und die IAccessible Schnitstelle.
(WPF User guggen wie immer in die Röhre weil sie auf diese Fire-And-Forget Technologie gesetzt haben die nicht im im mindesten so durdacht war wie Windows selbst)
Ja VS wird hier immer penibler - von Version zu Version bzw. neuerdings gibts ein Meldungsfenster wo früher Breakpoints einfach kommentarlos übergangen worden sind. Nach meinen Recherchen scheint sich VS2015 bzw. der neue Debugger etwas penibler zu verhalten wenn du in der Release Variante kompilierst. Einige Arbeitskollegen hatten das Problem auch und wir konnten das Problem auf die neueste .Net Version identifzieren und weniger auf VS2015. Bissl schwierig zu erklären, das neuere .Net Framework Code setzt stärker auf Linq und wer schon ma mitl Linq gearbeitet hat weiss das Edit-And-Continue in Methoden die Expressions vorkompilieren nicht funktioniert. Änderungen führen immer zum Abbruch oder dem übergehen der Breakpoints. Der Debugger scheint das neuerdings nicht mehr mit einer Abbruch-Meldung zu quitieren - sondern zeigt dann eben ein Meldungsfenster an. Es dazu nicht zwingend notwendig das du ausgerechnet was in der Methode wo das Problem auftritt geändert hast - das kann auch vorher/woanders passiert sein.
Also kurz gesagt ist das mein Stand der Erkentniss: Wo du vorher neu kompilieren musstest, muss man dass jetzt nicht mehr aber dann gibts halt dieses freundliche Hinweisfenster. Vermutlich gibts dafür sogar eine Einstellungsmöglichkeit und jemand hier im Forum weiss es vielleicht sogar.
Die Frage lässt sich natürlich nicht pauschal beantworten. Für den einen lohnt es sich und für den anderen wieder nicht.
Ich hab die DotNetro nun seid gut 15 Jahren im Abo. Als ich das Abo abgeschlossen habe hiess sie noch BasicPro und ein gewisser Ralph Westphal war ihr Chefredakteur, Damals war es eine Zeitschrift der Tipps und Tricks sowie HowTo's. Inzwischen bemüht sich die Zeitschrit mehr vor allem über aktuelle Microsoft Trends und Produktstrategien zu informieren. Wenn du Azure/JavaScript/Universal-Apps in deinem Kompetenz Gebiet liegen kannst du mit dem Abo nichts falsch machen. (Kritische Töne gibts generell nicht) Andernfalls kann man auf das Abo im Zweifel auch gerne verzichten. Es ist inzwischen eher so eine Art Informationsmagzin, wenn du allle sonstigen Blogs, Newsletter eh schon mitverflolgst würde ich dir als vermutlich -Einsteiger der um 150€ im Jahr rätselt- nicht raten.
(Achso wenn du gerne das Gesicht von Holger Schwichtenberg siehst und dem Entity Framework nachhängst ist es doch wieder gut investertes Geld)
Warun die Zeitschrift ihren Empty Space mit so Schaizz wie kochen mit Patrick auffüllt habe ich nie verstanden.
Wenn es eine Möglichkeit gibt an Office Automatisierung vorbei zu gehen würde ich dir in jedem Fall dazu raten.
Sofern du einfach nur ein Dokument generieren willst, braucht man dafür keine Fremdsteuerung der Office Anwendungen mehr(ab> Office 2007). Mit Ausnahme von PowerPoint gibt es dafür auch genug Open Source Projekte die den Umstieg hier einfach machen.
NetOffice ist ein Spezialfall und eigentlich mehr auf Addins ausgerichtet. Syntaktisch und sementisch ist es aber identisch zu den Interop Assemblies und setzt auf Automatisierung. Im Idealfall muss man hier nur ein Verweise und usings erstetzen um bestehenden Interop Code zum laufen zu bringen. Haben wir bei uns so gemacht und nie Probleme erfahren.
Es ist mir nicht klar wie eine DSL hier abhilfe leisten könnte. Eine Scriptsprache braucht man dann wenn man nachträglich benutzerdefinierte Logik erlauben/ausführen will. Eine DSL ist was völlig anderes. Ich kann da keinen Zusammenhang erkennen. Was hat eine DSL bitte mit einer nachträglich interpretierten Scriptsprache zu tun?
Microsoft hat vor einiger Zeit, weitgehend unbemerkt, ein Projekt für Probleme diese Art ins Leben gerufen.
Damit kann man VBA als auch JavaScript recht einfach mit eigenen Anwendungen verknüpfen. Das erscheint mir deutlich sinnvoller als eine neue Scriptsprache entwickeln zu wollen.