Beiträge von Andy

//PUSH
Ich werde mich mit UEZ Sonntag Mittag im Rhein-Main-Gebiet treffen, wer noch Lust hat mitzufahren soll sich melden.
Mit AutoIt-T-Shirts sind wir dann auch ausgestattet, bleibt online! Wir werden sicher mit Impressionen aufwarten, hoffentlich läuft die Außen-Webcam!

Ja, natürlich kannst du Programmteile oder Funktionen verwenden, dafür ist doch ein Forum da.

PushTheButton hätte längst ein kleines Upgrade nötig gehabt bzgl. einer Suchfunktion in ASM, sind ja nur ne Handvoll Befehle. Schaumamal, ob ich am Wochenende mal ne Stunde Zeit erübrige.
Obwohl die in nativem AutoItcode erledigte Suche idR. schnell genug ist. In Full-HD werden die Buttons aus nicht "direkt" anklickbaren Buttons selbst auf unseren Firmen-Nettops innerhalb von Millisekunden gefunden. Da habe ich mir sowieso angewöhnt, einige hundert Millisekunden zwischen den einzelnen Klicks zu warten, damit das System überhaupt hinterherkommt...

Schau mal hier, da habe ich die Geschichte mit Fadenkreuz, pixelgenauer Positionierung und Größe, Speichern und Suchen von Bildinhalten schon einmal umgesetzt.
PushTheButton, ermöglicht Mausklick auf sonst nicht erreichbare Grafiken UPDATE 1.36

//EDIT
Die Prospeed.dll braucht man bei heutigen Rechnern nicht mehr, einfach weglassen. Man muss auch im Script nichts ändern, die Bildausschnitte werden auch so in wenigen Millisekunden gefunden.

Hi,

Zitat von Eugen

Ich habe in der Gui einige Listenfelder und Inputboxen.

Zeig mal dein Script, damit klar wird, was du überhaupt vorhast.

Zitat von Eugen

Vorbelastet bin ich seid der Zeit von Commandore 64 mit basic und danach etwas Visual Basic 6. Beim 64er war ASM noch einfach.

ASM ist auch heute noch "einfach". Viel einfacher geht es garnicht. Aber "einfach" ist ja nicht das Ziel.
AutoIt hat den großen Vorteil der (sehr guten deutschen) Hilfe. Und eine schnelle Community. Wenn du "richtig" fragst und uns auch Material zum Arbeiten zur Verfügung stellst, bleibt die Hilfe sicher nicht aus.

Hi,
ich weiss nicht, warum Screencaptures gemacht werden, ich machs ohne, einfachstenfalls so:

#include <WinAPIGdi.au3>
#include <WindowsConstants.au3>

$hgui = GUICreate("Beispiel stretchblt()")
$hdc_gui = _WinAPI_GetDC($hgui) ;device context GUI
GUISetState(@SW_SHOW, $hgui) ;GUI sichtbar machen

$hDC_Screen = _WinAPI_GetDC(0) ;DC screen

Do
$x = MouseGetPos(0) ;Mauskoordinaten
$y = MouseGetPos(1)
_WinAPI_StretchBlt($hdc_gui, 0, 0, 400, 400, $hDC_Screen, $x, $y, 50, 50, $SRCCOPY) ;blitten
Until GUIGetMsg() = -3

Erklärung des RegEx: ^1?$|^(11+?)\1+$

^1?$ erster Teil findet Leerstring oder eine eins

^ start string
1? eine eins, null oder ein Mal
$ ende string

| oder (zweiter teil) ^(11+?)\1+$
^ start string
(11+?) Gruppe, welche 11 ein- oder mehrmals findet, diese Gruppe wird mit
\1 "gespeichert"
+ ein oder mehrmals
$ ende string

Durch das "backtracken" der RegEx-Engine entstehen bei beispielsweise 9 einsen folgende "Gruppen"
111111111
es wird mit Zweiergruppen 11 angefangen
11 11 11 11 die "übrige" eins matcht die Gruppe nicht, also backtrack mit 111
111 111 111 Gruppen matchen, also KEINE Primzahl

elf
11111111111
11 11 11 11 11 die "übrige" eins matcht die Gruppe nicht, also backtrack mit 111
111 111 111 die übrige 11 matched nicht, also backtrack mit 1111
1111 1111 die übrige 111 matched nicht, also backtrack mit 11111
11111 11111 die übrige 1 matched nicht, backtrack zuende, KEIN MATCH -> Primzahl
11111111111

Nicht schneller, sondern langsamer, aber dafür mit Spass!

;primzahlen ab 3 mittels regex

$string = "1"
For $i = 3 To 3000 Step 2
$string &= "11"
If Not StringRegExp($string, "^1?$|^(11+?)\1+$", 0) Then ;regex matched KEINE Primzahlen
ConsoleWrite('$i = ' & $i & @CRLF)
EndIf
Next

#include <Inet.au3>
#include <String.au3>

Local $sHTML = _INetGetSource("http://www.zks-abfall.de/DE/Home/homepage__node.html?__nnn=true")
Sleep(1000)
Local $Meldung = _StringBetween($sHTML, '<p class="MsoNormal">', '</p>'); Störmeldung auslesen

$Meldung[0] = BinaryToString($Meldung[0], 4);UTF8

ConsoleWrite("Meldung: " & $Meldung[0] & @CRLF)
MsgBox(64, "ZKS Meldung:", $Meldung[0])

UTF8 in der AutoIt-Hilfe eingegeben findet eine Handvoll Treffer....

Freitag startet das Event, mal sehen wo die Außenwebcams stehen, im letzten Jahr waren die in ca 2m Höhe im Inneren eines LKW montert. Je nach Brennweite und Bildausschnitt könnte ich mir vorstellen, ein ca. 1m² großes Plakat mit dem Autoit-Logo zu platzieren....
Die Security besteht allerdings sicherlich wieder aus denselben Jungs wie im letzten Jahr, und die sind definitiv nicht diskussionsfreudig, und Spass verstehen die auch nicht!
Schaumamal....

sagen wir mal so....es ist etwas vorbereitet

Naja, da ich sowieso hinfahre machen wir es wie beim letzten Mal, du sorgst für die Marschverpflegung

Hi,

wie schon in den letzten Jahren fahren UEZ und ich zur Revision 2015 nach Saarbrücken!

Gute Laune, laute Musik, geile Demos und witzige (bekloppte Grafik-) Freaks treffen ist GARANTIERT!
Zu Essen und zu Trinken gibt es reichlich, hoffentlich setzen sich die Organisatoren wie im letzten Jahr dafür ein, dass der (sehr gut schmeckende) Kaffee KOSTENLOS ist.

Die Revision geht über das Osterwochenende, unser Anreisedatum wäre der Sonntag, 5. April.
Wir würden zeitig vom Rhein-Main-Gebiet aus losfahren, und könnten ggf. unterwegs noch jemanden mitnehmen.

HIER Impressionen zur Revision aus dem letzten Jahr

Zitat von ShitDown

Selbst wenn man die Felder von 1x1px auf 20x20px vergrößern würde, kann es immer noch vorkommen dass ein Objekt 2 oder gar 4 Felder in irgend einer Weise anschneidet.

Stichwort Intersection.
Es ist völlig unerheblich, wie viele "Ecken" das Objekt hat.
Du kannst einen Umkreis bzw einen Innenkreis schlagen, welcher alle "Ecken" eines Polygons beinhaltet. Wichtig ist zu unterscheiden, ob überhaupt die Möglichkeit einer Kollision besteht.
Mal angenommen, du hast Objekte der Größe x*x und y*y Pixel (egal mit wievielen Ecken! ) .
Dann können sich diese Objekte niemals berühren,wenn der Abstand der Mittelpunkte diese Objekte mehr als (x+y)/2 beträgt.
Somit könnte man die schon von AspirinJunkie angesprochene Nearest Neighbour-Tabelle aufspannen....mit Abständen der Objekte.
Und erst wenn die Abstände innerhalb des kritischen Bereichs sind, brauchst du diese beiden Objekte per Intersect-Algorithmus auf Überschneidungen vergleichen.

Du musst dir je nach Anwendung einfallen lassen, was du genau willst.
Bei deinem Beispiel in Post#3 reicht eine "einfache" Abfrage auf doppelt vorhandene Positionen.

Speichere in jedem Feld die Nummer des jeweiligen Objektes.
Bei einer "Kollision" befinden sich mehrere Objekte in diesem Feld. Du brauchst also nur die Anzahl der Objekte (in diesem Fall 20) Abfragen!

Ja, ich gebe dir voll und ganz recht!
Wer keine Ahnung hat, der soll die Finger davon lassen!
Das gilt übrigens nicht nur für den Bereich "Paralleles Programmieren".
Nirgends steht geschrieben, dass diese Methode die einzig wahre ist. Allerdings halte ich es für eine sehr simple und zuverlässige Methode, um mit einer Handvoll Zeilen Code egal aus welcher Programmiersprache auch immer (nagut, Zugriff auf eine DLL sollte sie bieten ) einfache Interprozesskommunikation zu verwirklichen.
Wenn ich mir allerdings die gängigen Fragen hier im Forum zum Thema "gleichzeitig Funktionen laufen lassen" bzw. "AutoIt und Multithreading" anschaue, habe ich keine Angst, dass so jemand auch nur ansatzweise etwas über die von dir gemeinten "Gefahren" hören möchte...bzw. diese "Gefahren" auch nur im entferntesten versteht.

Gerade im Gegenteil finde ich es eher interessant, sich mit wirklich rudimentären Mitteln beschäftigen zu können um dann anhand bspw. dieser Konversation einen etwas tieferen Einblick in das Thema zu erhalten.
Der Weg ist das Ziel!
Oder wie der Franzose sagt, "learning by doing"!

//EDIT zum Script
Genau so meinte ich das mit der "Entwicklung". Sehr nice

Zitat von AspirinJunkie

Man muss sie beachten und mit geeigneten Mitteln verhindern.

Wahrscheinlich habe ich mich (wie so oft) unklar ausgedrückt...
Wenn du schreibst "MAN muss..und mit geeigneten Mitteln..." wer ist dann mit MAN gemeint? Natürlich ist es so, dass ausschliesslich der Programmierer für den Kram den er verzapft, verantwortlich zu machen ist.
Genauso wie übrigens

Zitat von AspirinJunkie

Klar lassen sie sich mit z.B. mit Mutex's oder Locks verhindern.

der Programmierer dafür sorgen muss!

Wer auch sonst?

Wenn per Lock/Mutex im VORFELD (!) gearbeitet wird, entstehen die angesprochenen "Probleme" erst garnicht! Im Umkehrschluss heisst das, dass bei Race Conditions (der "Zustand" existiert ! ) das Kind bereits in den Brunnen gefallen ist....die Existenz von Race Conditions impliziert schon den "nicht vermiedenen Fehler".

Zitat von AspirinJunkie

Mal ne Frage weil ich die SharedMemory.dll nicht kenne.

Thread dazu: Kommunikation Skripte untereinander

Im Prinzip wird nichts weiter gemacht, als per FASM eine DLL mit genau einer Funktionen zu erstellen, die lediglich den Pointer auf einen per sharable/writable gekennzeichneten Speicherbereich zurückgibt.
Ich bin mir nicht ganz sicher, ob dieses "Feature" überhaupt im Sinne des Erfinders ist, jedenfalls habe ich in einigen Foren in Threads zu diesem Thema festgestellt, dass irgendwann ein MS-Spezialist auftaucht, der einfach festlegt, dass so etwas garnicht funktioniert. Soviel dazu....

Threadsicherheit hatte ich ehrlich gesagt nie auf dem Schirm
Ich vermute aber, da es sich um eine einfache DLL handelt, dass das Betriebssystem bei Schreibzugriffen genau wie bei "gleichzeitigen" Aufrufen von Funktionen aus DLL´s handelt.
Bei Aufruf einer DLL-Funktion aus mehreren Threads wird jeweils ein lokaler Instructioncache angelegt und per Scheduler (vom Betriebssystem) abgearbeitet. Das ist simples Threadmanagement per Zeitscheiben.
Beim Zugriff auf "sharable" Speicher stelle ich mir ähnliches vor, ansonsten würde es permanent exceptions hageln.
Wenn also mehrere Threads "gleichzeitig" auf den von der DLL bereitgestellten Speicher zugreifen, managed das Betriebssystem die Zugriffe, ähnlich wie beim gleichzeitigen Zugriff auf Dateien.

Wie in diesem Post gezeigt, Kommunikation Skripte untereinander , ist "gleichzeitiges" Schreiben und Lesen völlig problemlos. Jedenfalls in dieser "einfachen" Form.

Aber zu deinen Fragen^^ :
"lost updates" sind ein Programm(ier(er))-Fehler. Wenn dieser Fall auftritt, hat irgendwer im VORFELD gepennt! Wenn bspw. 10 User "gleichzeitig" einen Wert in eine Datenbank schreiben wollen und dann keine Rückfrage an ALLE Beteiligten kommt, welcher dieser Werte denn nun "aktuell" ist, liegt imho der Fehler keinesfalls bei der Funktion "_DatenSchreiben()".
"Race conditions" sind imho per definitionem garnicht zu vermeiden! Das bekommt man nur dann geregelt, wenn (wiederum im Vorfeld! ) genau festgelegt wird, in welcher Reihenfolge Schreib/Lesezugriffe abgewickelt werden, also per vorher definierter, zeitlich bestimmter Prioritätenliste.
Stell dir vor, bei einem Leichtathletik-Wettkampf würde beim 100m-Lauf jeder Läufer einfach beim Startschuss losrennen und dann so schnell wie es ihm möglich ist, ins Ziel renenn! Wo kämen wir denn da hin! Chaos! Keinerlei Zuverlässigkeit in der Reihenfolge des Ziel-Einlaufs! Der schnellte wäre zuerst im Ziel.
Ein "richtiger" Programmierer würde in diesem Fall VORHER festlegen, in welcher Reihenfolge die Läufer im Ziel einzulaufen haben. DAS ist aber garnicht beabsichtigt....oder doch....oder doch nicht ?!

Hi,

Zitat von Freaky

B startet C 3x und D 1x

Ich möchte aber sowas wie, dass alle Cs auf die selbe Adresse zugreifen.

Beim von Homer J.S. verlinkten Post greifen ALLE Prozesse SIMULTAN auf den geteilten Speicher zu, das ist der Sinn der Sache!
JEDES der gestarteten Scripte initialisiert den Speicher über die DLL, alle nachfolgend gestarteten Scripte greifen auf diesen Speicherbereich zu.

Wenn man mag, kann man einzelne Speicherbereiche einfach über die Startadresse und das Offset selektiv benutzen.
Angenommen, man hat 8 Programme, die alle auf den gleichen Speicher zugreifen, dann ist das "normal". Gebraucht werden 10 KBytes, reserviert wird aber 1Mbyte.
Gleichzeitig benötigt man bei Programm5 bis Programm8 noch gemeinsamen Speicher, dann richtet man eben ab Offset 10 bis 20KB weiteren geteilten Speicher ein usw usf.
Habe das testweise auf Win Server8 mit 20 gleichzeitig laufenden, einzelnen Prozessen getestet, das funktioniert einwandfrei. Was auch niemanden wundern sollte, denn genau DAS ist der Grund, warum es überhaupt DLL´s gibt....

Ja, ernsthaft!
Mal abgesehen davon, dass es absolut keinen Grund für scriptbreaking changes in UDF´s gibt (man sollte mal hinterfragen, wieso das User Defined Functions genannt wird! ) wäre es wenigstens sinnvoll, die "bisherigen", sehr gut funktionierenden UDF´s mit dem ursprünglichen Namen mit in die aktuelle AutoItversion zu packen.

Gerade du müsstest es am allerbesten wissen! Wie oft hast du im letzten halben Jahr auf Threads wie diesen antworten müssen, obwohl die Scripte der User bisher einwandfrei funktioniert haben!?
Ich habe ja garnichts gegen "neue" und wegen mir auch "bessere" UDF´s, aber die sollen dann bitte schön auch entsprechend gekennzeichnet sein, so dass ICH als USER mir aussuchen kann, ob ich ein Script einfach nur (mit "alten" Funktionen) benutzen kann, oder mir die Mühe mache, alles umzuschreiben.
Zur Zeit ist es so, dass bestehende Unterverzeichnisse mit den darin befindlichen UDF´s einfach von einer neueren Version überbügelt werden. Woher soll der 08/15-User wissen, welche der "alten" UDF´s bzw. Funktionen von seinen Scripten gebraucht bzw. so weit benötigt werden, dass das Script nicht nur anstandslos funktioniert, sondern auch die erwarteten Ergebnisse liefert?

Stell dir vor, du arbeitest mit einer Branchensoftware FIBU-SOFT, welche regelmäßig mit Updates versorgt wird. Das ist heutzutage die Regel! Eines Morgens machst du den Rechner an und hunderte deiner Kollegen auch. Auf allen Bildschirmen erscheint
""\\software\FIBUSOFT\FIBU_SL.sqn" (52) : ==> Unknown function name.:
Local $oFIBUSOFT = _FIBUSOFTOpen($SLfile)"
Du rufst die Hotline des Softwareherstellers an und fragst, was da los ist. Als Antwort bekommst du:

Zitat von helpdesk

Über die Online-Docu von FIBU-SOFT gelangst Du zu "History / Changelog". Dort steht ganz am Anfang der Link zu den Script Breaking Changes.
Dort siehst Du dann, was sich zwischen der alten und der neuen Funktion geändert hat. Über den Eintrag zur FIBU-SOFT Bibliothek findest Du dann die
folgende Seite mit einer genauen Auflistung was sich geändert hat. (qed in Anlehnung an dein Post #7)

Und keine Angst, wenn die bisher von Ihnen erfassten Aufträge nicht mehr lesbar sein sollten, ändern Sie einfach folgende Datenfeldinhalte wie beschrieben ab...blablub

Eins kann ich dir schwören, dieser Fall tritt so NIE ein, denn keine Firma kann sich so etwas leisten!
Als Admin führst du dieses Gespräch auch garnicht, sondern stößt sofort ein Rollback an, direkt gefolgt von der Inrechnungstellung desselben!
Oder was würdest du in diesem Fall machen?

Wieso gibt es seitens AutoIt eigentlich keine Funktion, um diese "alten" UDF´s (die immerhin zusammen mit AutoIt ausgeliefert werden) direkt per Hinweis mit den "neuen" zu ersetzen?
Und die Funktionen im Script gleich mit....
Dann könnte man sich diesen und zig weitere Threads zu diesem Thema komplett sparen. Und die Aufgabe, teilweise hunderte von Scripten händisch umzuschreiben (und das ggf. beim nächsten Update wieder ! ) würde sich auf einige Mausklicks reduzieren.