SoftMaker.de

Lässt man ein Skript über eine Selection in PlanMaker laufen und benötigt die Abarbeitung einige Zeit, so kann man mit der Maus noch vor Abschluss der Arbeiten eine neue Selektion erzeugen. Das Skript fährt dann an der neuen Stelle mit der Bearbeitung fort.
Das sollte so ja nicht sein.

Gibt es eine Möglichkeit, das direkt per Befehl zu verhindern und die Anwendung zu blockieren? Und wenn es das nicht gibt... Es wird benötigt...

Umrechnung in Range ist auch keine Lösung, weil Range keine Löcher in der Selektion erlaubt und diese über Selection afaik nicht abgefragt werden können.

Stop! Das brauche ich unbedingt um gezielt weitere Bereiche abzufragen!

Prinzipiell aber gebe ich Dir absolut recht. Nur fehlt dafür ein (für PM) sehr wichtiges Dialog Steuerelement, was es aber in PM schon gibt, und wohl relativ einfach zu implementieren wäre.
Dieses hier:
Sag mal, was sind denn "Löcher in der Selektion" ? Meinst Du Selection - Kollektionen? Die sind m. W. sowieso (noch) nicht im Basic lesbar. Es wird immer nur die erste Auswahl wiedergegeben.

_________________
SMO rev. 670 + Win XP                    Times without money are better than times without Mini - the original

Es geht nur darum einen Schalter zu haben, der es verhindert die Selektion zu verändern. Das kann man dann nutzen, muss es aber nicht.


Wenn Du bspw. die Zellen A1:C8 markierst, dann STRG drückst und A12:C20 markierst gibt es zwei markierte Bereiche (diskontinuierliche Selektion). Gestern ist er irgendwie in den zweiten markierten Bereich gehopst und hat dort fleissig weiter bearbeitet. Heute bekomm' ich das aber nicht mehr dupliziert... Hmm... ...vielleicht war es auch ein Fehlerchen.

Dann dazu... ...es sollte möglich sein, alle einzelnen Selektionen abzufragen und dann entsprechend bearbeiten zu können, damit die Bearbeitung von diskontinuierlichen Blöcken möglich ist. Aber, das hat ja im Prinzip mit dem Verschieben von Selektionen zur Skriptlaufzeit nichts zu tun... Kommt dann später nochmal wieder auf die Tagesordnung...

Ja, Du meinst "Selection Collections" oder deutsch "Auswahl Sammlungen". Die kann SM-Basic nicht, ich habe es getestet.

Dazu müsste es eine Sammlung "Selections" geben (oder "Ranges"), mit einzelnen Elementen dieser Sammlung vom Typ Range.

(Auch ein Wunsch von mir.)

_________________
SMO rev. 670 + Win XP                    Times without money are better than times without Mini - the original

Ich hab nochmal Zeit in das engere Thema hier investiert.
Das OLE ist sehr langsam, wenn z.B. in PM Zellenweise größere Bereiche abgefragt werden. Ich habe schon Abstürze erlebt, weil ich dachte das Skript wäre längst fertig als ich munter an der Datei weiterarbeitete.

Auch mit Screenupdate = False kann man noch in PM (und TM?) währen des Skriptablaufs herumfuhrwerkeln. Die "Selection" einem Objekt zuzuweisen verhindert ebenfalls nicht dessen Inhalte währenddessen über die Anwendung zu verändern.

Die Bearbeitungsroutine des Skripts in eine Dialogfunktion zu packen hilft auch nicht, weil der Dialog in den Hintergrund verschwindet beim Klicken auf die Anwendung. Auch wenn der Dialog ständig reaktiviert wird, wieder sichtbar wird, hindert es nicht daran die Anwendung gleichzeitig zu bedienen.

Es gibt nur einen mir bekannten Ausweg: Application.Visible = False, und das wohl besser mit On Error Routine, und natürlich mit einem, während des Skriptablaufs offenen Anti-Schreck-Dialog (mit Dialogfunktion) gegen das verständliche "Huch!!?? Wo ist jetzt mein Dokument?"

Ergo: User-"Fehler" aufzufangen ist momentan etwas sehr aufwändig für ein paar Zeilen Skript die wirklich etwas "machen".
Könnte da mittelfristig vielleicht etwas geschehen, bitte?

_________________
SMO rev. 670 + Win XP                    Times without money are better than times without Mini - the original

Neee, nicht wirklich... Das geht auch irgendwie garnicht, denn für den Anwender sieht das ja dann immer so aus, als sei das Programm angestürzt, denn es verschwindet ja bis auf den Prozess vollständig und ist auch nicht mehr auffindbar. Das kann man für andere Dinge sicher gut gebrauchen, aber hier dann doch eher nicht.

Also mal sehen und bei Zeiten werde ich wohl eine SelectionToRange.Konvertierfunktion basteln (wenn dann nicht wieder irgendwas wichtiges fehlt), denn dann gibt es diese Probleme nicht. Range ist es schnurzegal, was mit der Maus angestellt wird...

Hallo,

nach Rücksprache mit den Entwicklern sollte 'pm.visible = FALSE' hier weiterhelfen können.

_________________
Sven Leßmann
SoftMaker Software GmbH

Ja, klar hilft das, aber damit wird die Anwendung ausgeblendet und da sie auch im TaskManager nur noch unter Prozesse auftaucht sieht es für den Anwender immer so aus, als sei das Programm abgestürzt. Eine wirkliche Lösung ist das leider nicht.

Bleibt also wirklich nur zu versuchen, Selection in Range umzurechnen. Mal sehen.

Es scheint, als sei das Verhalten, was den BM angeht grundlegend mit dem letzten SP geändert worden... Die Aktualisierung der Anzeige erfolgt jetzt erst nachdem alle Operationen abgeschlossen sind und eine Veränderung der Selection ist beim Ablauf des Skriptes nicht mehr möglich.

Fein, fein...

Sooo... Doch noch nicht erledigt... Wie habt ihr das angestellt? Irgendwas muss der BM doch mit dem PM anstellen um eine Änderung zu verhindern...

Greift eine nicht-BM-Anwendung auf den PM zu, so kann nämlich weiterhin fröhlich die Selection verschoben werden... Also macht das entweder der BM irgendwie und sperrt das, oder der PM wird irgendwie verändert... Gibt es eine neues OLE-Kommando, das der BM direkt anstösst? Wenn ja... heisst?

Oh oh. Wenn BM Dialoge jetzt auch modal sind ist meine SideBar ausgeträumt. Halb fertig schon für mein Stiefkind "ExcelseiteDrucken".

Hatte mich schon mit dem Stolperstein sehr gut angefreundet, er war sogar zum Edelstein avanciert.
Es erfordert aber Maßnahmen. Nichts für Neulinge.

_________________
SMO rev. 670 + Win XP                    Times without money are better than times without Mini - the original