Beiträge von BugFix

Zitat von attaxx

kommen wir zurueck zu meiner Frage

Das war eine Antwort auf deine Frage! Das Vermeiden und Abfangen von Fehlern ist die einzig akzeptable Lösung.
Du willst doch nicht ernsthaft Fehlbedienungen ermöglichen und wartest jetzt auf die Eierlegende Wollmilchsau, die diese Fehler für dich abstellt.. :wacko:

Ich war ein paar Tage nicht on und weiß daher nicht, was genau hier gesagt und als anstößig empfunden wurde.
Grundsätzlich bin ich gegen überzogene Reglementierung. Ob die Inhalte tasächlich irgendwelche FSK-Kriterien tangiert haben weiß ich nicht, hege aber meine Zweifel daran.
Wenn in der SB tote Hose ist, stört es mich persönlich nicht wenn artfremde Themen bearbeitet werden. Jedoch sollte sofort bei Auftreten von AutoIt-relevanten Postings darauf gebührend Rücksicht genommen werden.
Bei allen Themen macht der Ton die Musik. Und ein Gag wird nicht lustiger, wenn man diesen in 30 weiteren Varianten wiedergibt.
Also bei allem Maß halten und allen ist gedient.
Ich denke nicht, dass Jugendgefährdung in irgendeiner Weise hier im Raum steht - man kann seine Bewertung von Gelesenem auch mit der falschen Brille betrachten. Extremismus sollte in jeder Richtung unterbleiben.

Zitat von attaxx

aber z.b. dass dann Arrayfehlermeldungen dann nicht als Arrayfehlermeldung erscheinen sondern als z.B: Skript hat ein Fehler -> Crash

Sorry - aber so etwas DARF in einem kompilierten Skript nicht auftreten. Dann hast du fehlerhaft programmiert.
Bis zu 60 % macht das ordentliche Errorhandling in einem Programm aus. Du mußt jede noch so absurde Situation vorhersehen und abfangen. Crashen darf ein Skript niemals.
Die einzig zulässigen Fehlermeldungen sind Infos an den User, wenn er Fehleingaben getätigt hat.

Wenn deine Rechner(bzw. deine Hardwarekomponenten) in der Kompatibilitätsliste ist, kannst du auf Win7 ja ein Virtual XP nutzen. Mit HDD ist das relativ lahm beim Laden aber auf einer SSD gehts geschmeidig fix. Insofern habe ich bei mir auf Dualboot verzichtet und nutze XP bei Bedarf in der Virtual - Umgebung.

Vielleicht solltest du dein Embedded IE auch mal in eine GUI einbinden? Einfach nur das Objekt erstellen reicht nicht, von allein wird es sich in keine GUI einnisten.
Schau dir einfach mal das Hilfebsp. an.

Zitat von sc4ry

Kann ich per SQL mitgeben, dass er den a.title nur bis zu der Zeichenfolge " - " vergleichen soll?

Ja klar, deine Vergleichsmethode ist eigentlich einer SQL-DB unwürdig (mit "="). Damit findet man ja wirklich nur einen sehr fixen Datenbestand. Hast du schonmal was von LIKE gehört? Damit kannst du die Suche wesentlich flexibler gestalten. LIKE und IN sind meine persönlich am Häufigsten genutzten Suchmethoden.

Zitat von Bluesmaster

Falls letzteres kann ich nur empfehlen es als Standart-Einstellung zu handhaben, so funktionieren 90% aller Foren und wüsste nicht was dagegen spricht.

Ich bin der Meinung, weniger ist mehr. Wer möchte kann das ja aktivieren. Aber wozu soll ich unnötigen Traffic generieren, wenn es nicht gewollt ist?
Und ich suche das Forum ja nicht nur auf, wenn es eine Antwort auf ein bestimmtes Thema gegeben hat, dazu bin ich viel zu sehr Forist.

(übrigens heißt es Standard - einfach an Standardisierung denken ;))

Zitat von Bluesmaster

Frage beantwortet.

Bitte setze deinen Startpost auf "gelöst".

Alle AutoIt-Lösungen sind hier leider ein Rumgemurkse.
Verwende besser NirCmd.

Hi,

ist noch einfacher als ich dachte:

#Include <Constants.au3>
#Include <WinAPI.au3>

$WM_MEINE_MESSAGE = _WinAPI_RegisterWindowMessage("MEINE_MESSAGE")

$hGUI = GUICreate("Test")
GUISetState()

GUIRegisterMsg($WM_MEINE_MESSAGE , '_WM_MEINE_MESSAGE')

_SendString($hGUI, $WM_MEINE_MESSAGE, 'Test-String')

Func _SendString($hWnd, $iMsg, $sString)
_SendMessage($hWnd, $iMsg, StringLen($sString), $sString, 0, "wparam", "str")
; == als "wParam" übergibst du die Stringlänge, "lParam" wird nicht verwendet sondern "str"
; == In der Messagefunktion wird der String als Pointer empfangen
; == Mit Hilfe der übergebenen Stringlänge wird der Pointer in eine Struktur entladen und ausgelesen
EndFunc

Func _WM_MEINE_MESSAGE( $hWnd , $iMsg , $wParam , $lParam)
Local $sLen = BitAND($wParam, 0xFFFF) ; Low Word
Local $tMsg = DllStructCreate('char[' & $sLen & ']', $lParam)

ConsoleWrite(DllStructGetData($tMsg, 1) & @LF)
EndFunc

Edit:
Wenn du mit deiner eigenen Message unterschiedliche Varianten senden möchtest (also eventuell mal String, mal Struktur), kannst du dazu auch einfach "wparam" nutzen. Du setzt dann z.B. im Lo-Byte die Länge und im Hi-Byte "-1" als Trigger dass ein String übergeben wurde.
Hier mal im Bsp. beide Versionen

Zitat von Bluesmaster

Wie versende ich einen String als Window Message?

Ich habs bisher nicht gebraucht, würde aber versuchen den String in eine Struktur zu packen (0-terminiert) und dann versenden. Dann kannst du den empfangenen Pointer sofort in eine identische Struktur entpacken und hast den Wert.

Na die Funktion steckt doch drinnen: btMeasureClick() nimmt die Berechnung vor, mit den Werten die in der GUI eingegeben wurden.
Das su vereinzeln sollte doch kein Problem darstellen.

Nun, das kann natürlich nicht funktionieren, da du den Hook auf einem nicht existierenden Fensetr aufsetzt!

$autoItWin = WinGetHandle( AutoItWinGetTitle() )

Das gibt es gar nicht zu diesem Zeitpunkt.Verwende einfach mal:

$autoItWin = WinGetHandle( WinGetTitle('[ACTIVE]') )

, dann siehst du, dass es funktioniert.

Also ich kann einen Crash nur reproduzieren, wenn die Mainloop ohne jede Unterbrechung läuft.
Ich arbeite viel mit Message-Hooks und hatte bisher noch nie einen permanenten Fehler. AutoIt ist nicht optimal im Umgang mit Callbacks, aber trotzdem sind Crashs recht selten.
Ich habe z.B. ein Kontextmenü-Ctrl darauf basierend erstellt und das habe ich noch nie gecrasht.

Guckst du: Textmeter

Funktioniert tadellos, wenn du deine Programmschleife mal aus der Dauerlast nimmst und Sleep oder GuiGetMsg einbaust.

NB: "==" ist für sensitiven Vergleich bei Strings, für alle anderen Vergleiche reicht das "=".

Zitat

Excellent! Völlig unterschätzter Thread imo.

Danke.
Ich hoffe, du hast die im Startpost verlinkte AddOn-Variante (OwnHotKeys) verwendet. Die ist noch komfortabler und umfangreicher als die Variante aus diesem Thread hier.

Neue Funktion: OHK.ShellExecute() - beliebige Dateien mit ihrem verknüpften Programm ausführen
Vorerst noch nicht in der Datei enthalten, zur Integration siehe Post #1.

Zitat von progandy

Download und Dokumentation für die SciTE-ru GUI befinden sich hier:
http://scite-ru.googlecode.com/svn/trunk…/LuaLib/gui.dll
http://scite-ru.googlecode.com/svn/trunk…i/docs/gui.html

Ich habe heute erstmals versucht die gui.dll anzuwenden. Aber das ist leider eine Nullnummer. Die Dokumentation enthält ebenso, wie die Examples, Funktionen, die in der dll gar nicht existieren.

Wenn man die gui.dll einbindet werden folgende Funktionen nach SciTE exportiert:

add					
add_buttons			
add_column			
add_item			
add_tab				
autosize			
bounds				
clear				
client				
context_menu		
count				
delete_item			
get_item_data		
get_item_text		
get_selected_item	
get_selected_items	
get_text			
hide				
insert_item			
on_close			
on_double_click		
on_focus			
on_key				
on_select			
on_show				
position			
remove				
selected_count		
set_list_colour		
set_memo_colour		
set_selected_item	
set_text			
show				
size

colour_dlg   -- Farbauswahl
list         -- Listview
memo         -- Richedit
message      -- MessageBox
open_dlg     -- FileOpenDialog
panel        -- SeitenPanel
prompt_value -- InputBox
run          -- analog zu ShellExecute
tabbar       -- Tab Ctrl
toolbar 
window

Und gerade bei diesen fehlenden Punkten sind die Grafik-Objekte.
Die gui.dll ist somit leider nicht einsetzbar.
EDIT 19.01.2014
Ich muss mich korrigieren - die Dll ist einsetzbar. Allerdings ist sie (aus meiner Sicht) mit einem Syntax-Fehler behaftet, aus dem meine Verwirrung resultierte.
Bibliotheken lassen sich in Lua wie folgt einbinden:

-- Variante 1:
Variable = require "Modul"
-- Elemente des Moduls lassen sich mit "Variable.Element/Methode" ansprechen


-- Variante 2:
require "Modul"
-- Elemente des Moduls lassen sich mit "Modul.Element/Methode" ansprechen

Die gui.dll ermöglicht den Zugriff auf die Elemente nur mit Variante 2, wohingegen die Methoden auch mit Variante 1 exportiert werden. Da wurde wohl in der Dll geschlampt und vergessen die Objekte zu exportieren. Wenn man weiß, dass dem so ist, ist es ja nicht dramatisch. Aber diese Tatsache ist in der (sowieso unterirdisch mangelhaften) Doku nicht erwähnt.
Im Allgemeinen ist es empfehlenswert, Module mit Variante 1 zu laden, um diese in den Lokalen Space importieren zu können. Mit Variante 2 bin ich gezwungen immer den Globalen Space zu nutzen - und das ist eine Performancebremse. Lua hat die beste Performance im Lokalen Space.

Zitat von sc4ry

Eine Inputbox selber basteln ist zwar nicht so schwer, allerdings dürfte das bei FileSelectFolder schon wieder anders aussehen.

Nö, ist nicht schwer - solltest auch du auf die Reihe bekommen.