Laden...
M
michael.schoeppe myCSharp.de - Member
Vertriebsleiterassistent/EDV München Dabei seit 15.09.2005 17 Beiträge
Benutzerbeschreibung

Forenbeiträge von michael.schoeppe Ingesamt 17 Beiträge

30.03.2008 - 15:20 Uhr

Hallo zusammen,
ich besitze ein Grafiktablett mit drucksensitiven Stift (über 500 Druckstufen). Nun würde ich ganz gerne ein Programm schreiben das auch auf diesen Druck reagiert, also im Grunde ein Control welches die Druckstärke die auf das Control selber ausgeübt wird feststellen kann. Wie funktioniert das, wenn überhaupt? Wie kann ich auslesen/feststellen mit wieviel Druck ich den Stift gerade benutze?

Danke im voraus

08.05.2007 - 23:14 Uhr

Hi Borg,
ich habe mir den Code erst angeschaut nachdem ich meine Frage ins Forum gestellt habe. Leider wußte ich nicht so recht wonach ich suchen sollte. Wie ich ja schon angedeutet habe bin ich Anfänger (zumindest in dieser Sprache) und hatte also nur wage Vermutungen wonach ich suchen muß. Meine Vermutungen waren aber größtenteils falsch (wie Deine Antwort für mich ergeben hat), weshalb ich also auch irgendwie "blind" für den Inhalt der FormEx-Klasse war. Ich habe also gar nicht gemerkt das die Antwort vor mir liegt. Deswegen konnt ich keine konkrete Frage stellen.
Aber Du hast mir jetzt die richtige Richtung gezeigt, und trotz meines Anfänger-Status habe ich deine Lösung sogar verstanden 🙂

08.05.2007 - 22:02 Uhr

Hallo Herbivore,
ich weiß das Du Recht hast und da ich mich ja abschließend bei Borg nochmal bedankt habe, und das ganz ehrlich, denke ich habe ich auch niemanden verärgert. Natürlich war seine eigentliche Antwort sehr sachlich. Fand ich gut und ich hab mich auch darüber gefreut. Aber der erste Satz "Das Durchsuchen des Codes hat zehn Minuten gedauert" sowie der letzte Satz "Und hat nicht länger gedauert als das Posten solch langer Texte." fand ich unnötig weil diese Sätze einfach so genervt geklungen haben. Aber offensichtlich war meine Annahme falsch. Ich möchte das Thema aber jetzt nicht in einem Forum wie diesem weiter breit treten. Dafür ist das Forum nicht da.

Gruß
Michael

08.05.2007 - 19:33 Uhr

Hey Borg.
Danke für Deine Hilfe. Aber wenn Du ein Problem damit hast zu antworten dann laß es doch einfach. Allerdings dachte ich ein Forum ist dafür da Fragen zu stellen und Antworten zu finden, und zwar ohne sich dafür schuldig fühlen zu müssen das man noch ein Anfänger ist. Und nochwas: Ich habe den Code tatsächlich mal durchsucht (Bevor ich Deine Antwort las) und bin auch bis FormEx vorgedrungen. Nur habe ich es einfach nicht kapiert. Erst jetzt, nach Deiner Antwort, habe ich es verstanden. Also bevor ich jetzt noch irgendetwas anderes sage, sag ich einfach nochmal vielen Dank. Und das mein ich tatsächlich ernst.

06.05.2007 - 19:21 Uhr

Ich weiß nicht so recht wie das mit mdi funktionieren soll. Es sollten schon Fenster sein die sich nicht nur innerhalb eines Hauptfensters bewegen können. Also kein mdi. Eher so:

subform.Owner=mainform;

Auf diese Weise bleiben die Fenster die zu dem Hauptfenster gehören immer vor dem Hauptfenster, können aber frei auf dem Desktop verschoben werden.
Es geht mir um folgendes: Im Allgemeinen ist der Rahmen eines Fensters welches sich gerade im Vordergrund befindet (also aktiviert ist) dunkelblau (oder so ähnlich) und die Rahmen der Fenster die sich somit im Hintergrund befinden (also gerade nicht aktiviert sind) hellgrau oder hellblau (was auch immer). Ich möchte jetzt also gerne erreichen das alle Fenster (Form's) meines Programms gleichzeitig aktiviert sind, also zum einen den Dunkel Blauen Rahmen besitzen und zum anderen das ich nicht erst das nächste Fenster in meinem Programm anklicken muß um es zu aktivieren sondern gleich in ein Menü oder so des nächsten Fensters klicken kann. Ich weiß nicht wie ich es sonst noch beschreiben soll (habe schon einige Beiträge zu dem Thema in versch. Newsgroups usw. verfasst). Ich kann nur sagen so wie in Paint.NET (Siehe Dateianhang/Bild) oder zum Beispiel auch Adobe Photoshop.

Menu statt MenuStrip ist für mich keine Lösung. Mir gefällt einfach das Design, oder besser die Farbwahl eines MenuStrip besser wenn VisualStyles deaktiviert sind (Es sieht dann so aus wie in Visual C# Express Edition und nicht so knallbunt wie in Office 2003).
Mit allen Inhalten des Namespaces System.Windows.Forms.VisualStyles kenn ich mich nicht aus. Also auch nicht mit VisualStyleElement.Menu. Keine Ahnung was ich damit anfangen soll.

Trotzdem Danke
Michael

06.05.2007 - 12:20 Uhr

Hallo zusammen,
ich habe mir soeben Paint.NET installiert und wundere mich über einige Sachen die ich so auch gerne programmieren würde.

Zunächst einmal fällt auf das alle Fenster des Programms (Verlauf, Ebenenen usw. als auch das Hauptfenster als Besitzer) zumindest optisch zur gleichen Zeit aktiviert sind. Wenn ich selber so was programmiere, also zwei Fenster wobei das eine ein Hauptfenster und das andere als Besitzer das Hauptfenster hat, dann ist nur das Fenster aktiviert in dem ich gerade arbeite. Ich weiß das dies normales Windows-Verhalten ist, aber ich würde es gerne so machen wie in Paint.NET. In Paint.NET kann ich auch in irgendein Sub-Fenster klicken (bzw. darin arbeiten) und gleich darauf auf das z.B. Menü des Hauptfensters klicken. Würde ich meinem eben beschriebenen Programm noch ein Menü im Hauptfenster hinzufügen, so müßte ich das Hauptfenster jedes mal erst durch klicken auf z.B. die Titelleiste aktivieren, sofern ich gerade in meinem Sub-Fenster gearbeitet habe, um das Menü benutzen zu können. Und noch was ist mir aufgefallen: Das Menü (MenuStrip) sowie die Symbolleisten usw. von Paint.NET sehen vom Design so aus als wäre Application.EnableVisualStyles(); nicht verwendet worden (Ich arbeite unter XP). Aber ich habe gesehen das zumindest in einigen Sub-Fenstern diverse Buttons z.B. nen VisualStyle verwenden. Wie ist das zusammen vereinbar? EnableVisualStyles wurde offensichtlich nicht verwendet und doch sind VisualStyles zumindest teilweise aktiviert. Ich stelle diese Frage wie das geht weil mir nämlich ein MenuStrip ohne VisualStyle optisch viel besser gefällt.

Also vielleicht weiß jemand wie all diese von mir beschriebenen Dinge die man in Paint.NET sieht, realisieren kann.

Ich weiß das es den Sourcecode zu Paint.NET zum runterladen gibt. Aber ich hab nicht unbedingt die Zeit mich da durch zu arbeiten. Deswegen hoffe ich mir kann jemand hilfreiche Antworten geben.

Vielen Dank im voraus

19.06.2006 - 20:08 Uhr

Hallo zusammen,

wie das Thema schon andeutet versuche ich einen Gaussen Weichzeichner zu programmieren. Das Prinzip habe ich mir im Internet zusammengereimt:

Der Weichzeichner wird auf jeden Pixel des Bildes (Oder der Auswahl) angewendet.
Er setzt den Farbwert des jeweiligen Pixel auf den Mittelwert aller umliegenden Pixel in einem vorher festgelegten Radius.

Okey! Mein erster Versuch war grottenschlecht da ich bei jedem Pixel des Bildes erneut mit diversen Formeln (cosinus und sinus) die umliegenden Pixelpositionen berechnet habe um an die Farbinfo's zu kommen.
Bei einem Bild von 800600=480000 Pixel dauert das verdammt lang. Muß man doch bedenken das hier ganz grob geschätzt je nach Radius z.B. 20480000 Operationen getätigt werden. Zumindest wird 480000 mal der Radius berechnet, und das ist schon heftig.

In meinem Zweiten Versuch habe ich die Positionen (mittelpunkt war x=0, y=0) innerhalb des Radius gleich am Anfang erfasst und in eine ArrayList gespeichert. Die Positionen in der ArrayList habe ich dann immer um 1 erhöht wenn der Weichzeichner Pixel für Pixel über das Bild gewandert ist. So ist der Kreis mitgewandert. Aber auch das dauert noch zu lange.

In meinem dritten Versuch hab ich mal was neues Versucht: Habe eine Bitmap erstellt und in diese eine Ellipse nach Vorgabe gezeichnet. Hintergrund weiss, Ellipse Schwarz. Dann habe ich die Schwarzen Pixel erfasst und deren Positionen wieder in eine ArrayList geschrieben. Der Rest: Selbiges Spiel wie in Versuch 2.

Das ist alles schön und gut, aber daß was danach folgt bringt mich zur Verzweiflung. Denn zunächst einmal würde ich nicht behaupten einen dollen Algorithmus geschaffen zu haben, denn ich habe doch recht viele verschachtelte Schleifen verwendet. Schneller ist es jedenfalls nicht wirklich geworden. Und das Endresultat war immer entweder einfarbig oder mehr Rot als sonst was (Wie ein schlechtes, verrauschtes Bild). Allerdings liegt das möglicherweise an falscher Schleifenbindung o.ä.
Mit anderen Worten: Ich habe so gut wie nix erreicht.

Also kann mir da vielleicht jemand helfen? Wie beschleunige ich das ganze und liege ich mit dem was ich im Internet gelesen habe (siehe oben) richtig?
Vielleicht kann mir jemand sogar ein Code-Snippet o.ä. bieten aus dem ich lernen kann?
Desweiteren denke ich darüber nach die Bitmap in ein Byte-Array zu speichern, wie das geht weiß ich, um auf GetPixel und SetPixel zu verzichten und stattdessen die Werte in dem Array direkt zu bearbeiten. Ich erhoffe mir wenigstens dadurch einen Geschwindigkeitszuwachs. Allerdings habe ich festgestellt das mir die Werte die da in dem Array stehen nix sagen. Hat da jemand Ahnung?

Danke im voraus

05.04.2006 - 00:10 Uhr

Ich hatte auch schon an die Systemregistrierung gedacht. Doch schien mir das erstmal zu unsicher da ich nicht weiß ob der Eintrag auf allen Windows-Versionen am selben Ort innerhalb der Registrierung zu finden ist.

Das mit CurrentCulture hat mir schon einigermassen weitergeholfen. Zumindest denk ich muß ich nicht unbedingt den Umweg über System.Threading.Thread.CurrentCulture gehen. Wenn ich das so richtig gesehen habe kann ich auch direkt auf System.Globalization.CultureInfo zugreifen. Muß aber noch rumprobieren.

04.04.2006 - 23:13 Uhr

Hi!

Ich möchte gerne wissen ob es eine Möglichkeit gibt mit C# Bordmitteln die derzeit auf dem Betriebssystem eingestellte Sprache (Deutsch, Englisch, usw.) zu ermitteln. Unter System.Environment findet sich jedenfalls keine Methode zum auslesen der Sprache, wenn ich richtig geschaut habe.

Danke im voraus

20.03.2006 - 22:27 Uhr

So müßte es funktionieren:

watcher.Filter = "Bilddatei (.jpg;.bmp;.png;.tiff;.gif;.wmf)|.jpg;.bmp;.png;.tiff;.gif;.wmf";

Bei mir funktioniert es beim Filtern mit einem OpenFileDialog (Ich habe es mit Bildformaten gemacht wie Du in meinem Beispiel sehen kannst).
Mit diesem Watcher habe ich noch nie gearbeitet, deswegen nehm ich nur an das es ebenso funktioniert.
Kleiner Tip: Solltest Du den OpenFileDialog benutzen, so beachte das jeder Benutzer mittels . eingabe den Filter aushebeln kann. Auch nützt Dir der Filter nix wenn jemand eine vollkommen andere Datei erstellt (Laß es wegen mir nur eine Textdatei sein), die Extension aber auf eines Deiner Formate (.mp3 oder .wma) ändert (Beispiel: Textdatei.mp3).
Beim laden einer solch 'falschen' Datei würde sehr wahrscheinlich eine Fehlermeldung ausgelöst werden. Fang diese mit einem Try{} catch{} ab und Du hättest das Problem zumindest teilweise gelöst. Andere Audiofiles die nicht in Deinem Filter erscheinen aber von C# unterstützt werden würden allerdings keine Fehlermeldung auslösen. Deswegen meine ich 'teilweise gelöst'.

Ich hoffe das hilft Dir ein bißchen weiter, freue mich aber genauso wenn es auch anderen weiterhilft.

27.11.2005 - 15:08 Uhr

Also wie Du schon richtig sagst, herbivore, würde der Vergleich sicherlich ziemlich lange dauern. Mein Gedanke war das ja jede Datei einem bestimmten Ast der Registry entspricht. Mit dem Wissen bräuchte man dann nicht mehr die Gesamte Registry vergleichen, sondern nur noch den entsprechenden Ast (natürlich vom 'Root' abwärts). Aber wahrscheinlich würde das auch zu lange dauern. Vielleicht lasse ich es trotzdem mal auf einen Versuch ankommen.

Leider, Hauptmann, bin ich zu meiner Schande überhaupt nicht mit Kernelprogrammierung vertraut. Ich weiß zwar was der Kernel ist und wie er ungefähr arbeitet, das wars dann aber auch schon. Mal schauen: Vielleicht befasse ich mich in Zukunt auch mal mehr damit.

Trotzdem soweit Danke an alle

26.11.2005 - 10:00 Uhr

Du hast Recht,
so ein Programm soll es werden. Es soll allerdings später einmal auch Bestandteil eines Programms sein welches alle Aktionen erfasst wenn sich ein anderes Programm installiert und dieses dann ohne Restmüll wieder entfernen können.

Na ja! Es gibt da glaube ich noch ne andere Möglichkeit die mir da so vorschwebt:
Die Registry ist doch letztendlich auch nix anderes als eine Ansammlung von Dateien. Wenn man eben nur diese Dateien auf Änderungen überprüft (Das geht soweit ich weiß), dann weiß man zumindest das es in der Registry irgendeine Änderung gegeben hat. Welche, das kann man dann ja im Nachhinein überprüfen, sofern man natürlich vorher ein Abbild dieser Registrydateien sowie der Registry ansich zum Vergleich angelegt hat.

Mit anderen Worten: Das Programm erstellt beim Erststart Backups der Dateien und liest aus der Registry alles aus und speichert das. Alles zum Vergleich. Dann läuft das Programm im Hintergrund (als Dienst vielleicht) und überprüft die Registrydateien permanent ob sich was ändert. Wenn sich was ändert wird die Registry durchlaufen und mit den zuvor gespeicherten Registrydaten verglichen. Auf die Art findet dann das Programm die tatsächliche Änderung und meldet dieses. Wieder werden Backups gemacht um neue Vergleichswerte für mögliche spätere Änderungen zu haben.

Aber ganz ehrlich: Ich bin mit diesem Gedanken nicht unbedigt zufrieden. Ich hatte mir erhofft das es was simpleres gibt, wie ein bereits existierendes Event das in der Registry horcht z.B.
Denn am liebsten arbeite ich mit Bordmitteln. Man muß ja nicht mehr als nötig programmieren, gelle?
Aber nun gut! Ich werde auf jeden Fall auch meine Methode ausprobieren.
Aus welchen Dateien die Registry besteht weiß ich ja.
Hoffe trotzdem das vielleicht hier noch jemanden was einfällt.
Auf jeden Fall Danke schonmal

25.11.2005 - 22:27 Uhr

Hallo,

Ich möchte gerne eine Funktion in einem Programm das ich gerade schreibe, implementieren, welche die Registry permanent auf Änderungen (neue Einträge kommen hinzu, Einträge verändern sich, Einträge werden gelöscht usw.) überprüft und diese meldet. Klar könnte ich die gesamte Registry in einer Schleife auslesen lassen (simpler Gedanke), aber das wär wohl sehr Leistungsraubend denk ich. Gibt es da nicht eine besser Möglichkeit? Irgendetwas, was ich z.B. in der Sprachreferenz übersehen habe?

bin für jede Hilfe dankbar

18.09.2005 - 17:28 Uhr

Hallo,

Habe das Problem soeben folgendermaßen gelöst: Werkzeugfenster per Controls.Add in das Mdi-Hauptfenster einfügen, alle anderen Fenster normal per MdiParent einfügen. Damit ist das Werkzeugfenster immer im Vordergrund bleibt aber innerhalb des Hauptfensters. Nachteil: Das Werkzeugfenster erscheint (je nach Thema bzw. Farbeinstellung) in Graublau, also als wäre es nicht selektiert. Aber damit kann man doch leben, oder?

Möglicherweise hast Du Dein Problem schon auf Deine Art gelöst, denn Dein Beitrag ist ja schon ne Weile alt, aber vielleicht liest das hier jemand der die selben Probleme hat. Deswegen habe ich mal auf deinen Beitrag geantwortet.

18.09.2005 - 15:28 Uhr

Hallo Moq,

Auch ich wollte ein Werkzeugfenster in einem MDI-Container realisieren welches permanent im Vordergrund ist. Als ich dann deinen Beitrag gelesen habe, besonders das es in Photoshop ja auch so funktioniert, hat mich das auf die Idee gebracht mal in Photoshop und diversen anderen Anwendungen, welche auf meinem Rechner sind, nachzuschauen. Das Ergebniss ist, daß eben bei allen Aendungen, inklusive Photoshop, das Werkzeugfenster eben nicht im Hauptfenster eingefügt ist. Es sind selbstständige Fenster. Schau doch mal selber nach. Ändere die Größe deines Photoshop (oder welches Programm auch immer) Fensters und zieh mal das Werkzeugfenster über den Rand hinaus. Ich denke Du wirst das selbe wie ich feststellen. Im Grunde wird uns hier ein Werkezugfenster in einem Hauptfenster vorgegaukelt. Wie geschieht das:

  1. Starten wir solche Anwendungen meist maximiert (Korrekt?) weshalb man also nix über einen Rand hinaus schieben kann, weil der Rand ja schon am äußeren Bildschirmrand anliegt.
  2. Wird das Werkzeugfenster schon beim Programmstart so positioniert das es so ausschaut als befände es sich im Hauptfenster.

Aber wenn man nun doch unbedingt ein Werkzeugfenster innerhalb eines MDI-Containers realisieren möchte, das ständig im Vordergrund ist, so hätt ich diesen Vorschlag:
Erstelle ein Panel und füge es mittels Controls.Add(panel); in Dein Hauptfenster ein.
Erstelle ein Werkzeugfenster und füge es mittels Controls.Add(tools); in das Panel ein. Alle Controls haben die Eigenschaft sich in einem MDI-Container über alle MDI-Childs zu legen. Damit wäre dein Werkzeugfenster (Respektive Panel) immer im Vordergrund. Nun würde ich noch irgendwas programmieren das bei Bewegung deines Werkzeugfensters innerhalb des Panels das Panel selber mitbewegt wird. Aber damit habe ich mich noch nicht so beschäftigt.
Keine Ahnung ob ich Dir damit weiterhelfen konnte, aber ich hoffe doch wenigstens ein kleines bißchen.

15.09.2005 - 23:03 Uhr

Danke an beide. Das ging schnell 😁
Tatsächlich kannte ich mich noch gar nicht mit Mdi aus. Habe es aber jetzt so programmiert und das Verhalten der Fenster ist jetzt so wie ich es mir gewünscht habe.
Auch der Tip mit MaximizeBox (Ich dachte es dient nur dazu die Maximize-Schaltfläche aus der Titelleiste zu entfernen) hat super funktioniert.
Ich hatte gehofft das durch die änderung meines Hauptfensters in einen MdiContainer auch TopMost funktionieren würde (hätt ja sein können), aber das läuft immer noch nicht. Setze ich mein bisher einziges Werkzeugfenster auf TopMost=true; dann wird es trotzdem von allen anderen, oder besser gesagt von einem anderen gerade aktiven inneren Fenster überdeckt (Sorry wenn ich immer "inneres Fenster" sage: Ich bin Java gewohnt 'internalFrame').
Vielleicht kann mir da noch jemand nen Tip geben?

Danke nochmal

15.09.2005 - 21:37 Uhr

Hallo erstma,

Ich bin zur Zeit dabei ein kleines Programm zu entwickeln und bin zunächst erstmal dabei nur das GUI zu programmieren. Im Augenblick stelle ich mir vor: Ein Hauptfenster sowie einige Werkzeug und sonstige Fenster. Eben diese Fenster habe ich in das Hauptfenster mittels Controls.Add eingefügt. Soweit ist ja alles wunderbar, doch eines stört mich: Alle eingefügten Fenster schauen ohne Ausnahme optisch so aus als wären sie nicht aktiv. Das heißt Titelleiste und Rand Graublau anstatt das gesättigte Blau. Trotzdem ist natürlich eines der Fenster aktiv. Nur optisch eben nicht erkennbar. Warum ist das so? Kann man das ändern?
Desweiteren hätte ich gerne das einige der "inneren Fenster" permanent im Vordergrund sind und somit andere der "inneren Fenster" überdecken. Schön das TopMost=true; bei Fenstern ansich funktioniert, offensichtlich nicht aber bei inneren Fenstern. Vielleicht weiß da jemand Rat?
Und noch ne Frage, aber nicht so wichtige Frage: Warum maximiert ein FixedToolWindow trotzdem bei Doppelklick auf die Titelleiste? Ein FixedToolWindow soll doch in der Größe nicht veränderbar sein. Klar das ich mir mit nem Resize-Event abhilfe schaffe, sprich: Ändert sich die Größe (maximiert) so reagiert der Event und setzt WindowState wieder auf Normal.

Viele, viele Fragen.
Aber ich hoffe doch mir kann jemand helfen.
Danke im voraus