dann funktioniert es genau so, wie es soll
Ja, hatte ich in Post #3 ja dann bemerkt.
Ein Problem ist nur noch die Kontrolle, welches tatsächlich das Fenster ist, welches als aktiv betrachtet wird. GetForegroundWindow() liefert oft auch "0" als Ergebnis.
Ich wollte die Größe eines Fensters abfragen, aber die Funktion erzählt mir, das Handle sei ungültig. 
include winim/[inc\winuser]
var
h = GetForegroundWindow()
lpr: LPRECT
echo "Is Window? ", bool(IsWindow(h))
echo "Success? ", bool(GetWindowRect(h, lpr))
if GetLastError() == 1400: echo "ERROR_INVALID_WINDOW_HANDLE"Passiert das bei euch ebenso?
Dann prüfe doch erst mal, ob ControlGetPos überhaupt Erfolg hatte und ein Array erstellte.
$Start_Bar = ControlGetPos('','Browser',40965)
If Not IsArray($Start_Bar) Then Exit MsgBox(0, 'Fehler', 'ControlGetPos nicht erfolgreich')Nebenbei: Du wirst schwerlich ein Fenster identifizieren können, wenn du keinen Titel verwendest. 
Die Z-Order ist ja ein eher fiktiver Wert. Bei meiner Suche bin ich auf 99 Lösungswege gestoßen, die zu 150 Ergebnissen führen. 
Aber ernsthaft: Es scheint wohl kein gesichertes Verfahren zu geben, die Z-Order zu bestimmen. GetNextWindow wird nicht empfohlen, da zu unsafe. EnumChildWindows(hDesktop) liefert völlig andere Ergebnisse als EnumDesktopWindows().
Hier mal meine Variante mit EnumDesktopWindows() - aber ich vertraue den Werten nicht.
include winim/[inc\winuser]
import strutils
type
EnumWnd = object
hwnd: HWND
class: string
title: string
order: int
var
sEnumWnd: seq[EnumWnd] = @[]
lp: LPARAM
z = 0
proc my_WndEnumProc(hwnd: HWND, lp: LPARAM): WINBOOL {.stdcall.} =
if GetParent(hwnd) == 0:
var
buflen = GetWindowTextLengthW(hwnd) + 1
buf = newWideCString("", buflen)
className = newWideCString("", 4096)
discard GetWindowTextW(hwnd, cast[LPWSTR](addr buf[0]), buflen)
discard GetClassNameW(hwnd, cast[LPWSTR](className), 4096)
if buf.len != 0:
z += 1
sEnumWnd.add(EnumWnd(hwnd: hwnd,
class: $className,
title: $buf,
order: z))
return TRUE
proc GetDesktopWindows(): bool {.discardable.} =
sEnumWnd = @[]
return bool(EnumDesktopWindows(0, my_WndEnumProc, lp))
if GetDesktopWindows():
if sEnumWnd.len > 0:
for i in 0..sEnumWnd.len - 1:
echo "Z: ", sEnumWnd[i].order, "\thwnd: 0x", toHex(sEnumWnd[i].hwnd), "\t", sEnumWnd[i].title
else: echo "FAILED"OK, "MozillaWindowClass" war nur ein allgemeines Bsp. - wohl schlecht gewählt.
Ich habe jetzt alle Varianten durchgespielt, einzig mit SetForegroundWindow(hwnd) kann man ein existierendes Fenster anzeigen.
Was aber ein Problem ist: Ich finde gerade keine sichere Methode das aktive/Vordergrund Fenster zu ermitteln. Die Funktion GetActiveWindow() ist nur für Fenster im eigenen Thread zuständig - also unbrauchbar. GetForegroundWindow() liefert nicht immer das korrekte Handle. Wenn (was leider in Windows häufig passiert) das System für irgendeine vom User nicht veranlasste Aktion den Fokus vom aktiven Fenster nimmt, ist dieses nicht mehr aktiv und die Funktion liefert als Handle "0".
Ich werde mal testen, ob durch Kombination der Funktionen oder zusätzlicher Abfrage der Z-Order ein eindeutiges Ergebnis möglich ist.
Eine scheinbar simple Aufgabe: Ein Fenster nach vorn bringen (SW_SHOW, SW_SHOWNORMAL, BringWindowToTop). Alle 3 Versuche führen angeblich zum Erfolg: das aktive Fenster ist hinterher dasjenige, welches ich nach vorn bringen wollte. Aber sichtbar ist weiterhin das alte Fenster. Erst dachte ich, dass es aus dem Editor heraus fehlschlägt. Aber der Aufruf der exe aus einer Shell heraus bringt dasselbe Ergebnis. Das verwirrt mich. 
include winim/[inc\winuser]
import strutils
proc MyFindWindow(class = "", title = ""): HWND =
let
className = newWideCString(class, class.len)
wndName = newWideCString(title, title.len)
if class == "" and title == "":
result = FindWindowW(nil, nil)
elif class != "" and title == "":
result = FindWindowW(cast[LPWSTR](className), nil)
elif class == "" and title != "":
result = FindWindowW(nil, cast[LPWSTR](wndName))
else:
result = FindWindowW(cast[LPWSTR](className), cast[LPWSTR](wndName))
var hActive = MyFindWindow()
echo "ACTIVE: 0x", toHex(hActive)
let h = MyFindWindow(class="MozillaWindowClass")
echo "hWnd Mozilla: 0x", toHex(h)
if bool(IsWindow(h)):
BringWindowToTop(h) # ohne Erfolg, hActive ist angeblich hWnd
# ShowWindow(h, SW_SHOW) # ohne Erfolg, hActive ist angeblich hWnd
# ShowWindow(h, SW_SHOWNORMAL) # ohne Erfolg, hActive ist angeblich hWnd
hActive = MyFindWindow()
echo "ACTIVE: 0x", toHex(hActive)
if hActive != h: echo "Aktion fehlgeschlagen"
else:
echo "kein Handle"EDIT:
FindWindow ist nicht geeignet das aktive Fenster zu identifizieren. GetForeGroundWindow() ist die richtige Funktion dafür. Dann zeigt sich auch, dass das aktive Fenster sich nicht ändert, obwohl alle Funktionen Erfolg vermelden.
include winim/[inc\winuser]
import strutils
var hFore = GetForegroundWindow()
echo "Foreground Wnd: 0x", toHex(hFore)
let
class = "MozillaWindowClass"
h = FindWindowW(cast[LPWSTR](newWideCString(class, class.len)), nil)
echo "Mozilla: 0x", toHex(h)
if bool(IsWindow(h)):
echo bool(SetForegroundWindow(h)) # true
# echo bool(BringWindowToTop(h)) # true
# echo bool(ShowWindow(h, SW_SHOW)) # true
# echo bool(ShowWindow(h, SW_SHOWNORMAL)) # true
hFore = GetForegroundWindow()
echo "active Wnd: 0x", toHex(hFore)
if hFore != h: echo "Mozilla isn't active"
else:
echo "none window handle"BugFix
was meinst du zu dem Thema?
Ein Frühwerk von mir 
.
Meine Intention für diese Funktion lag eigentlich nicht im Sortieren einer Spalte (dafür ist es deutlich overdressed ). Ich hatte etliche Versuche unternommen mehrstufig zu Sortieren (wie z.B. in Excel: Hauptkriterium Spalte A, darin Sortieren nach B und darin Sortieren nach C - oder ähnlich). Im reinen Array-Sortiermodus ist das m. M. nach nur mit sehr hohem Aufwand realisierbar. Und somit lohnt sich der Aufwand bei mehrstufiger Sortierung durchaus.
Was deine Sortierprobleme angeht stimme ich dem Link von AspirinJunkie zu. Mit einem Überladen der Sortierfunktion kann man das Problem dann wohl lösen. Ich schreibs mal als Notiz auf meine Agenda - rechne aber nicht mit schneller Realisierung, ich habe im Moment zu viele offene Baustellen.
Ethernet gibt es nicht und die Datenmenge, die über die SIM-Karte übertragen wird, ist mehr, als gebucht wurde. Nach ein paar Tagen fällt die Geschwindigkeit auf Modemzeiten zurück
Und weshalb soll dann ein Bild!! übertragen werden, noch dazu im Minutentakt? Das ist doch eine völlig unnütze Verschwendung eurer raren Onlinekapazität. Dafür reichen doch ein paar Byte in Textform. Zu einer Grafik kann man das dann nach Empfang ja wieder aufhübschen.
Ich greif das noch mal kurz auf, da ich etwas gebraucht habe, um verschachtelte Pointer aufzulösen (wenn man weiß, wie es geht, ist es natürlich einfach ).
Hier mal ein einfaches Bsp.:
# Typ definieren Objekt intern
type
o1 = object
a, b: int
# Typ definieren Objekt extern
type
o2 = object
ointern: ptr o1
name: string
# Typ 1 Variable erstellen und befüllen
var oo1 = o1(a: 25, b: 2)
# Typ 2 Variable erstellen und befüllen
var oo2 = o2(ointern: addr oo1, name: "oIntern")
# alles in einem Pointer ablegen
var po2 = addr oo2
# Funktion, die einen Pointer als Parameter verwendet
proc SomeProc(p: ptr) {.discardable.} =
# Pointer auflösen in einzelne Werte
var
oEx: o2 = p[] # Pointer dereferieren mit []
oIn: o1 = oEx.ointern[]
echo oEx.name, "\t", oIn.a, "\t", oIn.b
SomeProc(po2)Gibt einen absoluten Pfad zurück der relativ zu $sBasePath erzeugt wird. Um dieses Vorgehen zu verhindern ist ein absoluter Pfad zu verwenden.
Diese (sachlich falsche!) Formulierung auszuschließen war doch das Ziel.
- Es ist ein relativer Pfad zu übergeben
- Dieser wird dann in Relation zum Basepfad gesetzt (Standard: WorkingDir). Basepfad MUSS absolut sein
- Ergebnis ist wiederum ein absoluter Pfad
Das ist es, was die Funktion tut.
Die Hinweise auf UNC Laufwerk und Basepfad halte ich für verständlich.
Relative Pfade dürfen nicht mit "\" beginnen.
Das ist eine Selbstverständlichkeit. Relative Adressierung geht nur mit "." oder ".."
Aber was machen wir nun mit der Beschreibung in der Hilfe? Kann das jemand so zusammenfassen, dass es einen Sinn ergibt?
Erstellt einen absoluten Pfad aus einer relativen Pfadangabe im Verhältnis zu einem Basispfad, welcher als absoluter Pfad zu übergeben ist. Standardmäßig ist dies @WorkingDir
Was nutzt du denn statt _PathSplit?
Und gibt es außer _PathFull eine andere Möglichkeit, um Pfadangaben mit Punkten in absolute Pfade zu wandeln? (z. B. @ScriptDir & "\..\..\MeinProgDir\test.txt")
#include <WinAPIFiles.au3>
ConsoleWrite( _WinAPI_GetFullPathName("..\Beispiele\") & @CRLF)Ich verwende meine eigene Funktion: Pfad-Funktion mit Struktur
insgesamt betrachtet ist die Funktion aber eher ein Witz.
Als ich mit AutoIt angefangen hatte, habe ich die Path-Funktionen natürlich auch alle getestet, bin aber schnell zu dem Schluss gekommen, dass ich es doch besser selbst mache, denn ich spiele nicht gerne russisches Roulett.
Alle 4 Pfadfunktionen sind mit wenig Nutzen behaftet. Verwendet habe ich vor vielen Jahren mal _PathSplit, würde ich auch nicht mehr nehmen, einfach viel zu umständlich (für meinen Geschmack). Warum soll ich für jeden möglichen Pfadteil vorher eine Variable deklarieren, wenn ich dann nur 1 davon benötige und als Return sowieso ein Array mit allen Werten kommt?
Aber man sollte dem Autor zugute halten, dass er eine Idee hatte und diese umgesetzt hat. Ich muss ganz ehrlich sagen, dass ich bei einigen meiner eigenen UDF nach heutigem Wissenstand durchaus auch an deren Notwendigkeit zweifle.
SendMessageCallback
Damit hatte ich auch schon geliebäugelt. Allerdings fremdele ich mit der Parameter-Beschreibung: "A pointer to a callback function that the system calls after the window procedure processes the message."
Würde ich jetzt lesen als: "Ein Zeiger auf eine Callbackfunktion, die das System aufruft, nachdem die Fensterprozedur die Nachricht verarbeitet hat."
Kann sein, dass ich das einfach falsch verstehe, aber erwarten würde ich:
"Ein Zeiger auf eine Rückruffunktion, die das System aufruft, nachdem die Fensterprozedur die Nachricht empfangen hat."
Ich will ja keine Nachricht senden, sondern auf eine empfangene Nachricht hin reagieren. Falls die Funktion das tut, ist der Name m.M. nach etwas unglücklich, "ReceiveMessageCallback" hielte ich für passender. Ich probiere es einfach mal aus.
Ich suche mir gerade in den Dateien der wnim und winim Module die Finger wund.
Es sollte doch eine Möglichkeit vorgesehen sein, eigene Messageauswertungen auszuführen. Ich suche also eine Prozedur, der ich eine Message und den Funktionspointer für meine Callbackfunktion übergebe. Wenn dann in der Mainloop diese Message auftaucht wird die Callbackfunktion aufgerufen, also genau das, was in AutoIt mit GuiRegisterMsg vorgenommen wird.
Die mainLoop Prozedur finden wir in der wApp.nim (#212). Dort folgend sind einige Funktionen zu Messages, jedoch keine, die erlauben auf Msg zu reagieren. In der wWindow.nim (#1273) gibt es die Prozedur processMessage. Das sah auf den ersten Blick recht erfolgversprechend aus, ist aber auch nur ein Funktion zum Agieren statt zum ReAgieren.
Vielleicht habt ihr ja einen klugen Gedanken.
Warum krampfhaft nach einer Funktion in der WinAPI suchen, die alle Eventualitäten berücksichtigt? Kann man doch selber machen.
Eine passende Lösung habe ich vor 5 Jahren mal hier gepostet.
Wichtig: RAID ist NICHT das Richtige für Datensicherung!
JEIN. Ein SYSTEM, das mit RAID läuft ist natürlich keine Datensicherung. Für Datensicherung sollte immer ein externer Datenträger verwendet werden. Und für diesen Datenträger gilt: Datensicherung ist NICHTS ohne RAID (Spiegelvarianten)! GVS (Großvater-Vater-Sohn auf 3 Datenträgern) Sicherung ist eher problematisch, wenn nicht zusätzlich, wie von AspirinJunkie erwähnt, Snapshots erstellt werden, ein Tag (der aktuelle) wäre ansonsten im Notfall futsch.
Kann man die Platten an keinen neuen Controller anschließen? Sind die Informationen auf dem Controller gespeichert oder warum geht alles den Bach runter wenn dieser ausfällt?
Der Controller war damals schon 8 Jahre alt und kein baugleicher mehr erhältlich, dadurch gab es die Probleme. Wenn man jetzt ein NAS eines soliden Herstellers verwendet (oder die Pi - Version, wie von AspirinJunkie vorgeschlagen), hat man dann auch keine Probleme.
Ansonsten, einfacher und besser: ich mache mir für diese Anzeige ein eigenes Control wie alpines geschrieben hat. Das Muster von Dir oben beinhaltet ja alles was ich brauche.
Oder du nimmst ein RichEdit-Ctrl. Könnte für dein Vorhaben passen.
RAID 1 sollte für dich passen. Bevorzuge ich persönlich auch. Ich habe bisher immer Hardware Controller verwendet. Bin ich zwar auch mal auf die Nase gefallen (nach Controller Ausfall, war kein Zugriff auf das RAID-Array mehr möglich) - aber das war vor 15 Jahren und da gab es zum Teil noch unausgereifte Technik.
Zu Software Controllern kann ich somit nichts sagen.
