|
| |
VB.NET - Fortgeschrittene| Weitere Instanz der Anwendung | |  | | Autor: msSuper | | Datum: 14.08.17 11:36 |
| Zur Zeit habe ich "Einzelinstanzanwendung=JA" verhindert, dass meine Anwendung auf dem einem PC mehrfach gestartet wird.
Mit _StartupNextInstance .. fange ich dann weitere Aufrufe bspw. über die Kommando Zeile ab.
Das funktioniert auch sehr gut.
Nun hätte ich aber trotzdem gerne, dass man mit einem speziellen Kommandozeilen Parameter eine separate Instanz bekommt.
Der Hintergrund ist, das es bestimmten Personen möglich sein soll, das Hauptprogramm offen zu halten, indem bspw ein Dialog mit ShowDialog geöffnet ist und in der zweiten Instanz - völlig unabhängig davon - ein ganz anderes Fenster ungehindert geöffnet wird.
Gibt es dafür eine Lösung? | |
| Re: Weitere Instanz der Anwendung | | | | Autor: Manfred X | | Datum: 14.08.17 13:31 |
| Hallo!
Wieso wird eine zweite Instanz benötigt?
Was ist gemeint mit, die zweite Instanz soll "völlig unabhängig davon"
"ungehindert" ein Fenster öffnen können? Unabhängig in welcher Hinsicht?
Wie ist diese "bestimmte Personengruppe" definiert?
Über die Windows-Anmeldung? Gibt es programmspezifische Nutzergruppen?
Zielt die Frage auf Datensicherheit? Auf Vermeidung programmtechnischer
Probleme (z.B. Zugriffs-Konflikte)? Oder worauf sonst? | |
| Re: Weitere Instanz der Anwendung | | | | Autor: msSuper | | Datum: 14.08.17 14:52 |
| Hier ein paar weitere Informationen...
Die Windowsanmeldung gibt den Benutzernamen und damit hole ich aus der Datenbank die Benutzergruppe, aus der dann die jeweiligen Rechte definiert werden. (Alles bereits fertig)
In der Tat ist es zur Zeit eine SingleInstanzanwendung, damit verhindert wird, dass ein und derselbe Anwender
den Kundenstamm mehrfach öffnet und dort den selben Kunden mehrfach editiert.
In Bezug auf andere Benutzer ist das so gelöst, dass per Datenbank der Kundendatensatz nur einmal zum schreiben geöffnet sein darf. Der nächste Benutzer kann den Datensatz während dieser Zeit nur lesend öffnen.
(Alles bereits fertig)
Das Unabhängig bezieht sich darauf, das die unterschiedlichen Windows Forms Fenster aus einem Menü (Treeview) aufgerufen werden und im Prinzip mit ...ShowDialog aufgerufen werden.
Dieses ShowDialog behindert somit den Aufruf aus dem Hauptmenü.
Unabhängig wäre es, wenn dann bestimmte Anwender die komplette exe nochmal starten könnten und dann wieder an das Menü können und somit in einer weiteren Instanz andere Daten bearbeiten können.
Beispielsweise ist der Kundenstamm des Kunden A geöffnet und in der zweiten Instanz wird der Kunde B geöffnet und ich kann die Bemerkung von Kunde A auf den Kunden B per Zwischenablage kopieren.
Natürlich könnte ich ShowDialog an einigen Stellen durch Show austauschen. ABER, komplett lässt sich das eben nicht vermeiden. Bspw. wenn beim Kunden die Zahlungsbedingungen eingetragen sind, möchte ich diese in einem Selektionsfenster auswählen können um diese dann in den Kunden zu übernehmen.
DropDown Boxen sind da meist zu unflexibel, wenn es darum geht, Filter und Selektionskriterien aufzubauen und eine Vielzahl an Spalten anzuzeigen.
Zur Zeit an ich zwar das Menü erneut aufrufen um wieder andere Formen (z.B. Kunden C) zu öffnen. Kann diesen editieren ABER - nicht in den zuerst geöffneten (Kunden A) einkopieren, weil Kunde C per ShowDialog geöffnet ist. | |
| Re: Weitere Instanz der Anwendung | | | | Autor: Manfred X | | Datum: 14.08.17 19:40 |
| Hallo!
Wenn Du bei der Schreibabfrage von (Kunden-) Datensätzen in der
Datenbank einen Sperrvermerk hinterläßt, der so lange gilt, bis
das Update-Kommando dieser Datensätze abschließend gegeben worden ist,
läßt sich unterbinden, daß jemand zwischenzeitlich diese Sätze erneut
für Update-Operationen abfragen kann.
Bei geeigneter Gestaltung der Vermerke und Abfragen spielt es keine Rolle,
wer diese Abfragen ausführen möchte - einmal abgefragt, wird der Sperr-
Vermerk (Zeitstempel, Nutzerstempel) bei den entsprechenden Sätzen gesetzt.
Falls ich das "Fenster-Problem" richtig verstanden habe, wäre eventuell
ein MDI-Projekt für Dich geeignet. | |
| Re: Weitere Instanz der Anwendung | | | | Autor: msSuper | | Datum: 15.08.17 08:44 |
| Vielen Dank für die bisherigen Hinweise, beim Thema "Weitere Instanz" reden wir scheinbar ein wenig aneinander vorbei, bzw. meinen vielleicht unterschiedliche Dinge.
Das Sperren und Abfragen funktioniert ja bereits gut und daran möchte ich gar nichts mehr ändern.
MDI Fenster kenne ich- und habe sie auch teilweise eingesetzt.
Trotzdem gibt es immer mal Fenster, die ich mit ShowDialog aufrufe.
Z.B., damit ein Wert aus einer komplizierten Tabelle (...mit mehrfacher Filterung, Sortiermöglichkeiten) gewählt werden kann, der dann z.B. im Kundenstamm übernommen wird.
Was könnte ich dort außer ShowDialog tun, damit ich
a) den Wert nach Auswahl sauber zurück schreiben kann (Datenbank und Kundenstammfenster (... aus dem ich die Auswahl aufgerufen habe))
b) damit der Anwender währenddessen (=völlig unabhängig) ein ganz anderen Stammsatz öffnen und editieren kann.
Hier wäre es sehr simpel, wenn ich mein Programm.EXE einfach in einer zweiten Instanz öffnen könnte.
Natürlich könnte ich den Schalter Einzelinstanz erstellen auf "NEIN" stellen und dann wäre dieses Problem gelöst.
Aber dann würde ich ein neues Problem bekommen, da mein Programm per Kommandozeilenparameter häufig von einer Zweiten Anwendung aufgerufen wird, z.B. um Etiketten auszudrucken.
Bei der bisherigen Einstellung "Einzelinstanz=JA" bleibt mein Programm im Speicher (und damit auch alle Initialisierungen beim Programmstart).
Durch MyApplication_StartupNextInstance bekomme ich den weiteren Aufruf mit und kann das Etikett (etc. ) drucken. (Auch dann wenn meine Anwendung ansonsten ein ShowDialog ausführt)
Schalte ich "Einzelinstanz=NEIN" wird bei jedem Programmaufruf jedes mal die Initialisierung aufgerufen, was das System natürlich unheimlich belastet und langsam macht. | |
| Re: Weitere Instanz der Anwendung | | | | Autor: sv00010 | | Datum: 15.08.17 17:47 |
| | Zitat: | |
Hier wäre es sehr simpel, wenn ich mein Programm.EXE einfach
in einer zweiten Instanz öffnen könnte.
| |
Die Frage ist ob es etwas nützt, die benötigten Funktionen in eine dll auszulagern, was allerdings doch erheblich mit Arbeit verbunden wäre. | |
| Re: Weitere Instanz der Anwendung | | | | Autor: msSuper | | Datum: 16.08.17 07:52 |
| Danke HenryV!
Mit Hilfe der Mutex Klasse bekomme ich es zumindest hin zu erkennen, wenn die Anwendung auf "Mehrfachinstanz zulassen" steht, ob sie dann mehrfach gestartet wurde.
Das Gleiche erreiche ich aber auch über die Auflistung der Prozesse. Oder etwa nicht?!?
Nun könnte ich das Problem wie folgt lösen:
1. Anwendung auf Mehrfachinstanz zulassen
2. Beim Starten abfragen, ob mehrfach gestartet ist,
a. wenn NEIN ist, (also erste Instanz) starte ich eine Überwachung mit der FileSystemWatcherKasse auf einen
bestimmten temporärer Ordner
3. Wenn mehrfach gestartet wurde, wird die Kommandozeile ausgewertet
a. Bei Kommando für weitere Instanz starten, das Programm weiter laufen lassen (Unabhängiger volle Instanz)
b. Bei anderen Kommando, diese in eine neu erstellte Datei (im überwachten Ordner) speichern.
Die aktuelle Instanz dann beenden.
4. Die erste laufende Instanz, erkennt dann die neue Datei und arbeitet den dort geschriebenen Parameter ab
(z.B. Druck eines Etikett)
Das ist zwar sehr umständlich, aber immer noch deutlich weniger Rechenaufwand, als die komplette
Anwendung zu starten.
Schöner wäre es natürlich, wenn ich per Mutex oder über den Process Handle einen Parameter an die erste Instanz weiter geben könnte und dort eine SUB ausführen. Dazu habe ich aber bisher nichts gefunden. | |
| Re: Weitere Instanz der Anwendung | | | | Autor: Blackbox | | Datum: 16.08.17 20:33 |
| Hallo,
die Lösung ist eine Semaphore, die auf 2 eingestellt ist.
Wie Du die in .NET einsetzen kannst - weiß ich nicht.
Im klassichen VB wird sie im Startmodul eingesetzt. | |
| Re: Weitere Instanz der Anwendung | | | | Autor: msSuper | | Datum: 21.08.17 13:14 |
| Zur Info.
Mein Plan ist leider gescheitert.
Die Überwachung per FileWatcherKlasse funktioniert gut.
Aber ab dann hagelt es Probleme mit Threadings.
Der zweite Aufruf aus dem FileWatcherEvent wird nicht so abgewickelt wie die
Private Sub MyApplication_StartupNextInstance(ByVal sender As Object, ByVal e As Microsoft.VisualBasic.ApplicationServices.StartupNextInstanceEventArgs) Handles Me.StartupNextInstance
Hier drinnen kann ich jederzeit ohne Probleme:
Dim CommandLine As System.Collections.ObjectModel.ReadOnlyCollection(Of _
String)
CommandLine = e.CommandLine
If CommandLine.Count > 0 Then
Dim cLine1 As String = cNoNull(CommandLine(0))
If cLine1.Length > 0 Then
frmMenue.verteile_big(cLine, True)
End If
End IfDie verteile_big aufrufen, welche mir die Command Line auswerten und entsprechende weitere Fenster öffnet.
Gibt es eine Methode dieses Ereignis also Me.StartupNextInstance zu feuern, auch dann wenn die Einstellung auf "Einzelinstanzanwendung erstellen = JA" steht? | |
 | Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.
 Einloggen | Neu registrieren |
 |
|
sevOutBar 4.0 
Vertikale Menüleisten
á la Outlook
Erstellen von Outlook ähnlichen Benutzer- interfaces - mit beliebig vielen Gruppen und Symboleinträgen. Moderner OfficeXP-Style mit Farbverläufen, Balloon-Tips, u.v.m. Weitere InfosTipp des Monats Access-Tools Vol.1 
Über 400 MByte Inhalt
Mehr als 250 Access-Beispiele, 25 Add-Ins und ActiveX-Komponenten, 16 VB-Projekt inkl. Source, mehr als 320 Tipps & Tricks für Access und VB
Nur 24,95 EURWeitere Infos
|
Mai 2024
Sie sind aktuell nicht angemeldet.