Laden...

Forenbeiträge von ujr Ingesamt 1.688 Beiträge

17.09.2012 - 17:41 Uhr

Control Panel > Region and Language, Date and time formats: Short date: "dd.M.yyyy"

Oder automatisiert in der Registry:
HKCU\Control Panel\International\sShortDate

14.09.2012 - 10:42 Uhr

Hallo,

bei mir (auch 96dpi) platziert folgendes Programm das Fenster alle 5s exakt an der Mausposition:


DispatcherTimer dt = new DispatcherTimer();

        public MainWindow()
        {
            InitializeComponent();

            ResizeMode = ResizeMode.NoResize;
            WindowStyle = WindowStyle.None;

            dt.Interval = TimeSpan.FromSeconds(5);
            dt.Tick += new EventHandler(dt_Tick);
            dt.Start();
        }

        void dt_Tick(object sender, EventArgs e)
        {
            System.Drawing.Point point = System.Windows.Forms.Control.MousePosition;
            Left = point.X;
            Top = point.Y;
        }

Es bleibt immer noch die Frage, woher Du die "72" in der Umrechnung hast.

14.09.2012 - 10:10 Uhr

Hmmm - welche DPI-Einstellung hat denn Dein Rechner?

14.09.2012 - 09:17 Uhr

ich will das aber nicht per Code machen sondern :::

Dann musst Du das UserControl selbst editieren. Das ist sonst vom Designer her unveränderlich. Woher soll der Designer schließlich wissen, dass Du Controls in ein darin liegendes Grid einfügen willst?
Würdest Du nicht ein UserControl nehmen, sondern bspw. ein Grid (und von diesem ableiten), dann funktioniert's wahrscheinlich.

14.09.2012 - 08:41 Uhr

Hallo,

was ist das denn für ein "UserControl"?

14.09.2012 - 08:32 Uhr

Mach ich die Umrechnung von System.Drawing.Point auf System.Windows.Point richtig oder hab ich was übersehen?

Wie kommst Du auf diese Umrechnung? Schonmal ohne probiert?

12.09.2012 - 11:10 Uhr

Hallo,

Du hast ein (Beispiel-) Projekt basierend auf WPF. Dazu gehören Dateien wie Window.xaml und Window.xaml.cs. Die kopierst Du zu Deinem WinForms-Projekt und bindest sie in dieses Projekt ein.
Wenn Du alle Verweise (PresentationCore usw.) zum WinForms-Projekt hinzugefügt hast, kannst Du z. B. mit

(WPFNamespace.)Window win=new (WPFNamespace.)Window();
win.Show();

dieses Fenster anzeigen. Wie Du das rahmenlos bekommst, findest Du sicher in der Doku des WPF-Fensters (war wohl WindowStyle und ResizeMode).

12.09.2012 - 08:34 Uhr

HA! In einem neuen Projekt tritt der Fehler nicht auf.
Bringt mich aber nicht wirklich weiter...

Nun ja, Du könntest Dein Projekt neu anlegen - also alle Dateien kopieren und hinzufügen, Referenzen und Einstellungen anpassen. Nicht schön, aber i. allg. auch nicht sooo viel Arbeit.

11.09.2012 - 15:30 Uhr

Hallo,

man kann auch ohne Komplettumstellung ein WPF-Fenster in einer WinForms-Anwendung erzeugen und anzeigen: Verweise hinzufügen, Quelltext kopieren, Fenster erzeugen, anzeigen. "Hosten" braucht man eher für UserControls.

11.09.2012 - 15:26 Uhr

Noch ein Versuch: Passiert das auch mit einem neu erstellten Projekt?
Könnte helfen laut: Open existing WPF project with vs2012 : XAML : An unhandled execption has occured : system.nullreferenceexception

Edit: Scheint auch der Poster aus dem Forum zu sein, ohne seine "Lösung" im Forum publik zu machen.

11.09.2012 - 14:01 Uhr

Ohne Quelltext kann man nur raten (Layoutcontainer, Positionierung, ...). Kürze den XAML-Code soweit, dass eine ansonsten vollständige ("lauffähige") Datei übrig bleibt, die den Fehler zeigt.

11.09.2012 - 12:13 Uhr

Dennoch fände ich es toll, wenn mir noch jemand einen Rat geben könnte, wie ich einzelne Datentypen manuell serialisieren kann (oder einzelne Operationen, falls es für Datentypen nicht möglich ist). Dies wäre insofern eine Verbesserung aus meiner Sicht, da ich nicht für jedes Objekt eine eigene Klasse anlegen müsste

In dem von Dir verlinkten Artikel steht:

Finally, the serializer. Implementing a new WCF serializer is a matter of finding a mapping between XML (the internal format used by WCF messages) and the format you want.

Wie sieht denn Dein Format aus? Vielleicht hilft Dir ja auch einer der JSON-Serialisierer von Codeplex?

11.09.2012 - 12:05 Uhr

Bestimmte Labels sind falsch ausgerichtet.

Wie denn "falsch"? Und was heißt "sind fest"?

Hast Du die Display dpi schon verglichen?

11.09.2012 - 12:01 Uhr

Kenn hier jemand eine Lösung?

Nein - aber hast Du schon versucht, die VS Einstellungen zurückzusetzen und Extensions zu deaktivieren?
Und hilft "Projektmappe bereinigen"?

Wie verhält sich VS, wenn Du XAML immer im Code-Editor öffnest und den Designer später startest?

03.09.2012 - 14:54 Uhr

Was meinst du mit "handelt es sich um das richtige Image"?

Du empfängst Daten und speicherst sie ohne weitere Umwandlung auf HD. Das sollte doch dem originalen Bild entsprechen. Tut es das?
Und mit "leichter" meinte ich genau dies - empfangene Daten werden ohne Umwandlung durch GDI gespeichert.

Hast Du schon mal, nur testweise, das Dispose vom Image aus dem Empfangsthread genommen? Tritt auch dann der Fehler auf?

03.09.2012 - 13:45 Uhr

So, wie der Code da steht, ist deine setImageOnPictureBox-Methode aber falsch implementiert. Da, was nach dem If-Block vom InvokeRequired steht, muss in einen else-Zweig (und darf bei einem InvokeRequired==true nicht ausgeführt werden).

Da steht doch aber ein "return" im if() - insofern ist's doch korrekt.

Versuch mal, nach dem Schreiben der Daten den ms.Position auf 0 zu setzen.

Schon mal versucht, die Daten direkt nach dem Empfang auf die Platte zu schreiben? Handelt es sich um das richtige Image?
Und wäre das nicht sowieso viel einfacher?

30.08.2012 - 14:32 Uhr

Ich hoffe das ganze ist nun etwas klarer.

Leider nein, da Du noch immer nicht die wirklich relevanten Code-Teile gepostet hast.

30.08.2012 - 13:00 Uhr

Hallo,

public class MyClass : INotifyPropertyChanged  

ist dabei wie oben aufgebaut.

es ist nicht so fein, dies nachträglich hinzuzufügen.

Auch kann man aus diesen Bruchstücken wie "false" überhaupt nichts sinnvolle unternehmen.

Wo wird die Klasse erzeugt? Wie denkst Du zu erreichen, dass Deine erzeugt Instanz überhaupt benutzt wird? Wie erfolgt die Bindung? Was ist "bla.Overlay", was "LoadingScreenOverlayEnable"?

30.08.2012 - 09:27 Uhr

Habe eine INstanz der Klasse erzeugt und ändere an gegebener Stelle den Wert, aber trotzdem passiert nichts.

[Hinweis] Wie poste ich richtig? 5

29.08.2012 - 18:12 Uhr

Hallo,

vielleicht hilft das:
AddRange and ObservableCollection

27.08.2012 - 10:02 Uhr

Das Ding ist, dass dort nicht nur ein Backgroundworker gestartet wird. Und bevor der Mainthread weitermachen darf, müssen alle Backgroundworker durchgelaufen sein.

Warten im GUI-Thread darf man nicht (s. oben verlinkte FAQ). Für Dein Problem bietet sich eher so etwas an: SyncQueue <T> - Eine praktische Job-Queue

Edit: etwas deutlicher noch - benutze einen BackgroundWorker, der die Queue abarbeitet, zählen im "Progress"-Event, und fertig bei "Completed".

27.08.2012 - 09:50 Uhr

Nein - es ist schon richtig, dass der GUI-Thread den BackgroundWorker erstellt. Nur dann kann man aus dem Completed-Ereignis auch ohne weiteres auf Controls zugreifen ( [FAQ] Controls von Thread aktualisieren lassen (Control.Invoke/Dispatcher.Invoke) ).
Der Fehler entsteht wohl dadurch, dass Dein GUI-Thread irgendwo und irgendwie blockiert bzw. wartet. Das darf nicht sein (und macht ja sonst auch den BackgroundWorker irgendwie überflüssig): [FAQ] Warum blockiert mein GUI?
Diese Stelle musst Du finden und korrigieren.

26.08.2012 - 00:08 Uhr

Nun führe ich in meiner Methode folgenden Code aus :

Wie wird die Methode aufgerufen (Callstack) und was passiert danach?

Was hast Du für eine Anwendung? Console, Windows Forms, WPF?

Jemand eine Idee warum mein CompletedEvent nicht ausgelöst wird ?!

Z. B., wenn Du einen GUI-Thread hast und dieser blockiert ist (Endlosschleife, Sleep, lock, ...), kann der BackgroundWorker nicht in den Kontext des GUI-Threads wechseln, um das RunWorkerCompleted auszuführen.

23.08.2012 - 09:48 Uhr

Also ich verstehe unter einer Invariante dass immer vor und nach einem Aufruf von außen das Objekt in sich stimmig sein

Hmmm, "invariant" ist "unveränderlich", "in sich stimmig" ist "gültig" bzw. "valide". Also doch eher das, was FZelle meinte?

Und wirklich "unverändert" ist doch die Collection nicht. Man könnte zwar den Zustand "gültig" als "invariant" ansehen - aber das ist vielleicht etwas weit hergeholt.

21.08.2012 - 11:37 Uhr

Hallo,

(sleep.exe aus den GNU shellutils für Windows)

falls die gerade nicht zur Verfügung steht, tut es auch das ping-Kommando 😁

ping -n 10 localhost > nul
21.08.2012 - 11:29 Uhr

Hallo,

Du solltest allerdings vermeiden, innerhalb erst und jedes Mal der Schleife zu prüfen, ob Wildcards enthalten sind und die dann jedes Mal neu umzuwandeln.

vor allem auch, weil die Regex jedes Mal neu erzeugt werden. Es könnte schon helfen, anstatt der ExcludeFiles die Regex in einem Array zu speichern und zu verwenden.

Beim Kopieren mit File.Copy werden im übrigen auch Win32-Funktionen aufgerufen, sollte also ähnlich schnell sein. Die Geschwindigkeit kann man selbst mir asynchronem Lesen/Schreiben von Puffern jedenfalls nicht erreichen.

20.08.2012 - 18:07 Uhr

Eine Lösung könnte sein, einen Dienst mit erhöhten Rechten laufen zu lassen und dann mit diesem zu kommunizieren (IPC).

19.07.2012 - 10:27 Uhr

Mit dem Programm Unlocker kann ich sehen, das der Prozess XYZ.vshost.exe immer noch ein Dateihandle auf die XYZ.exe hat. Ich werde weiter in die Richtung schauen.

Kann es sein, dass Dein Programm noch läuft? Schonmal Shift-F5 probiert?

19.07.2012 - 10:22 Uhr

Hallo,

hier ist ein weiterer Thread zum Thema - vielleicht hilft etwas davon:
Visual Studio 2010 build file lock issues
Oder hier
visual studio keeps locking files

In meinem Fall war es, bzw. ist es (eine endgültige Lösung habe ich bisher nicht), eine WCF-Assembly in Verbindung mit einer Mixed-Mode-Assembly. Wenn irgendein, völlig unabhängiges, Projekt der Projektmappe debuggt wurde.
Starten ohne zu debuggen funktionierte. Es half zwar, die Projekt-Type-ID aus dem WCF-Projekt zu entfernen, aber das beraubt einen natürlich aller Vorteile wie svcconfig oder Dienstverweise aus dem VS, ist also auch keine Lösung.
Leider wurde der Bugreport ohne Kommentar als "Zurückgestellt" geschlossen - sehr seltsam.

Will sagen, die Gründe können sehr komplex sein.

19.07.2012 - 10:12 Uhr

außer wie gesagt durch Process.Kill()

Verbleibt dann nicht das TrayIcon in der Anzeige?

Ansonsten kannt Du ja alle möglichen Formen der IPC verwenden, um Dein Programm zu beenden. Ein Fenster braucht man nicht unbedingt.

19.07.2012 - 10:03 Uhr

Das Problem wurde schon mehrmals besprochen

Allerdings gibt's die "ultimative" Lösung nicht.

In einem ähnlichen Fall wurde mir von Microsoft übrigens geraten, das Projekt mit VS2012 zu testen - da wären viele solcher Fälle behoben. Traf bei mir leider nicht zu.

@carl:
Was für Projekte hast Du in Deiner Projektmappe?

15.07.2012 - 21:54 Uhr

Die beiden Softwareprogramme liegen nicht im Programpfad sondern im Netzlaufwerk.

Wie passt das zu "c:..." aus dem ersten Beitrag?

Das Benutzerverzeichnis würde nur bewirken dass wenn 2 Benutzer es benutzen, dass die Daten getrennt abgelegt würden und nicht in der gleichen Datenbank liegen.

Und das ist nicht der Fall oder soll nicht der Fall sein?
Vielleicht legst Du die Datenbank unter "All Users" ab? Im Programmverzeichnis jedenfalls ist sie fehlplatziert.

zuerst solltest du schauen, ob es bei den NTFS-Rechten für die Ordner und Dateien irgendwelche Unterschiede gibt.

... oder ob das "Read-Only-Attribut" gesetzt ist.

13.07.2012 - 14:11 Uhr

Hallo,

hilft das vielleicht:
.NET 2.0~3.5 Compile to .NET 4.0

Oder eine Recherche nach der englischen Warnung (s. Link)?

09.07.2012 - 12:02 Uhr

U.a. habe ich BASS.NET entdeckt. Generell soll es wohl damit möglich sein, über das Netzwerk zu streamen. Hier ist die Dokumentation zwar ganz gut gepflegt, doch es gibt zu wenige Tutorials o.ä., sodass ich bis heute nicht einmal einen Ansatzpunkt habe, wie ich damit Netzwerkstreaming realisieren könnte.

"BASS_Encode_ServerInit" wäre ein Startpunkt. Ansonsten ist das Forum auf www.un4seen.com immer sehr hilfreich.

09.07.2012 - 10:55 Uhr

Hallo,

Aber wirklich anders würde es mir wohl als Einsteiger auch nicht gehen bzw. geht es mir unter Java auch nicht.
Klar - Informationen findet man überall

Das empfand ich sogar als großes Problem - es gibt im Grunde zu viele Informationen, abertausende Tutorials. Und leider veralten diese zu schnell.
Als wir mit .Net anfingen, existierte .Net 2.0 schon für eine gewisse Zeit (~1 Jahr). Es gab aber, bspw., jede Menge Tutorials oder Blogs, die zeigten, wie man XML parst und dafür .Net 1.1 Mittel verwendet haben, weil das zur Zeit der Erstellung aktuell war. Die Einordnung ohne vernünftige Übersichten fiel sehr schwer und verursachte gewisse Unsicherheiten.
Ein anderes Beispiel ist die Entwicklung von WPF aus Avalon - viele Informationen waren aufgrund geänderter API (und wenn es nur der XML Namespace war) schon beim Release von .Net 3 einfach veraltet.
So entsteht aus dem Vorteil der Dynamik der Entwicklung tatsächlich ein Nachteil.

Ein anderer Punkt ist die Dokumentation. Zum großen Teil werden auch in Büchern bei Neuauflagen viele Altlasten mitgeschleppt. Die MSDN ist zwar ein sehr gutes Referenzwerk - aber dazu muss man ja wenigstens die Klasse kennen. Oder Namespaces raten. Da sich aber etwa eine BindingList unter System.ComponentModel und nicht unter System.Collections befindet, ist das eine sehr unsichere Methode.
Eine richtige Framework-Referenz (gedruckt) gab es wohl zuletzt unter .Net 2.0 (in 6-7 Bänden). Wie umfassend die tatsächlich war, kann ich nicht sagen. Jedenfalls habe ich aber kein Buch gefunden, das wirklich "alles" behandelt hat - von P/Invoke, über COM bis Remoting. Und nein - jetzt brauch' ich es nicht mehr...

05.07.2012 - 12:09 Uhr

Und was würde das hinzufügen von :::

Genau das sollte aber die "richtige" Behebung der Warnung sein: diese sagt ja gerade, dass die neue Property/Methode die alte ausblendet und man "new" verwenden soll, wenn das beabsichtigt ist. Auch das "virtual" ändert daran nichts.

Edit: "override" lässt ja schon der Compiler nicht zu.

05.07.2012 - 09:20 Uhr

Hmm werden bei ASP.net nicht tatsächlich source dateien veröffentlicht die erst beim ersten aufruf compiliert werden?

Nicht unbedingt - wenn der C#-Code nicht in einer (bspw.) .ashx-Datei, sondern in einer separaten Code-Behind-Datei liegt. Dann gibt's eine DLL.

Als "Zwitter" kann man vor allem C++/CLI-Assemblies sehen, die ohne P/Invoke managed und unmanaged Code enthalten können.

04.07.2012 - 10:30 Uhr

Kannst Du nicht WM_QUERYENDSESSION benutzen?

28.06.2012 - 09:26 Uhr

(bzw. deren Assemblies bzw. deren COM-DLLs)

wie z. B. eine Shellerweiterung. Langsam herantasten mit Hilfe von ShellExView

21.06.2012 - 14:20 Uhr

Ist aber trotzdem etwas verrückt, da ich zum einen das Event vom Scanner bekomme und dann dadurch das Event vom KeyDown auslöse.
Damit hätte ich gedacht wieder im Main-Thread zu sein. Sonst hätte es ja auch zwingend ein Invoke benötigt um mein DataGrid zu aktualisieren./

Vermutlich bist Du immer im Main-Thread. Wie löst Du denn KeyDown aus? Durch Aufruf? Das führt zu keinem Thread-Kontext-Wechsel.

Dann wird es aber auch keinen besseren Workaround geben, als den Scanner immer zu aktivieren und wieder zu deaktivieren, da ich das sonst nie synchron bekomme 😕

Dann deaktivierst Du den Scanner aus seiner Ereignisbehandlung heraus? Auch nicht schick.

Du könntest mal versuchen, bspw. KeyDown über MainForm.BeginInvoke aufzurufen - und wenn's nur zum Test ist.

21.06.2012 - 10:45 Uhr

dass ich ja aus dem Event des Scanners wieder den Scanner aufrufe... Das könnte natürlich der Knackpunkt sein oO

Darauf wollte ich hinaus 😁
Darum funktioniert's auch beim Start des Programms, da dort keine analoge Kette aufgebaut wurde.

21.06.2012 - 10:23 Uhr

Hallo,

wodurch wird eigentlich "Aktion()" aufgerufen? Wie sieht der Call-Stack aus?

19.06.2012 - 10:27 Uhr

Hallo,

wo und wie erzeugst Du die Klasse RFIDScanner (bzw. in dieser die Hardwareanbindung)? Was ist RFIDScanner?

Kann ja schlecht das Fenster in einem anderen Thread Modal aufrufen. Oder ist das etwa die dreckige Lösung?

Ich würde mal versuchen, RFIDScanner (wenn es unabhängig von der GUI ist) in einem separaten Thread zu erzeugen, diesen auch bis zum Programmende nicht zu beenden (ManualResetEvent), und dann alle Zugriffe aus den Eventhandlern wie in [FAQ] Controls von Thread aktualisieren lassen (Control.Invoke/Dispatcher.Invoke) benutzen.

15.06.2012 - 12:06 Uhr

Um das auszuschließen werde ich bei mir noch die CRLF einfügen, wie sie auch bei der Testanwendung sind.

Weiter oben ist bei Dir aber gerade ein CRLF, während in der Testanwendung keines ist.

Aber was ist denn nun mit den Unterschieden in den Ziffern (7 <-> 1)?

15.06.2012 - 11:54 Uhr

Dass die Zeichen vor <?xml... nicht übereinstimmen ist Absicht? Auch der zusätzliche Zeilenumbruch?