Beiträge von Andy

Ich würde es so machen:

Bei der (Erst-)Anmeldung eines Users liegt das AutoItscript im autostart und wertet den schon von BugFix angesprochenen @username aus.

Das Script schreibt die INI-Datei der Telefonsoftware entsprechend des Users um, startet diese und voila....

Zitat von Manuel.P

Was ich nur nicht versteh ist, das Telefonprogramm schaut doch immer nur in die eine INI Datei,

eben

Da ihr nur EIN Telefonprogramm habt, ergo auch nur EINE INI-Datei habt...

Zitat von Manuel.P

Die Datei liegt unter C:\ProgramData\Telefonprogramm

...nutzt dir dein AD-nichts! Es würde dann immer nur der letzte angemeldete User "aktiv" sein.

Sollte allerdings die Telefonsoftware netztwerkfähig und somit Multiusertauglich sein, könnte das von mir oben beschriebene Procedere funktionieren. Denn dann wird bei jedem (erst-) anmelden eines Users die Software im Userkontext gestartet, die "eigene" INI-Datei ausgelesen und dem User die Telefonnummer zugeteilt.

Was, wenn sich auf dem PC bspw. 5 User anmelden, dazu führt, dass das dort danebenstehende Telefon auch beim Anruf an diesen 5 (verschiedenen) Telefonnummern klingelt. Und das ist doch wohl die Absicht, oder?

...doch...alles gut^^

Du setzt mit der Funktion die ANZAHL der zu benutzenden Cores, bei 3 werden also 3 Cores benutzt. Soweit so gut...

Um Jetzt den Thread einem (oder mehreren) dieser Prozessoren zuzuordnen , musst du SetThreadAffinityMask verwenden

//EDIT

so wie ich das sehe, wird HT (welches sowieso nur virtuell) ist, "abgeschaltet". Wie es sich gehört, wird die volle Core-Performance ausgenutzt! Daher sieht man im Ressourcenmonitor auch nur die Last auf dem jeweils "ersten" Kern, also CPU0, CPU2, CPU4 usw

Hi!

Zitat von alpines

Das ist leider das Problem wenn verschiedene Leute an den UDFs basteln, es gibt generell in den UDFs (bis auf die _GUICtrlxxx_bla Konvention) nichts was UDFs gemeinsam hätten.

Einige wollen unbedingt Arrayreferenzen, andere akzeptieren auch Kopien. Einige geben Integer zurück und andere Strings und dann sucht man sich die Finger wund.

Um es mal in meiner liebreizenden Art auszudrücken: "Wo ist der Bus mit den Leuten drin die DAS interessiert?"

Eine UDF ist per definitionem eine USER DEFINED FUNCTION. Und dabei liegt der Fokus auf User!

Und derjenige User, der sich die Arbeit macht und eine Funktion erstellt, mit einem Header ausstattet, und dann "selbstverständlich" nach Jahren noch dafür Support leistet in Form von "...leg mir mal den Arm aus der Sonne und schreib DEINE UDF so um dass ich damit auch noch blablub machen kann..." hat imho das ALLEINIGE Recht die von ihm erstellte Funktion so zu gestalten wie er das für richtig oder auch notwendig hält!

Es bleibt jedem freigestellt, die *glücklicherweise* allgemein verfügbaren (aka UD-) Funktionen nach eigenem Gusto anzupassen und zu modifizieren.

Meiner Meinung nach ist es ist der Job der Entwickler, aus den "Unterstrich_Funktionen()" ein einheitliches Konzept zu machen und dieses dann in die "blauen" (internen) AutoIt-Funktionen zu überführen. Dann ist/wäre die "UDF" in einem AutoIt-Update ersetzt durch die dann neue interne Funktion. Aber wer soll DAS denn machen?! Da gibt es wahrlich größere Baustellen in AutoIt :o), und die Zahl der "Developer" dünnt sich auch immer mehr aus....

Ich für meinen Teil passe regelmäßig die unterschiedlichsten Funktionen an meine individuellen Bedürfnisse an. Daher wächst und gedeiht mein "User Include"-Ordner prächtig

Und genau so sollte es auch sein!

Es gibt sowieso genug C&P-"Programmierer" die statt im Wust der (schon erwähnt KOSTENLOS verfügbaren) Funktionen etwas passendes zu suchen einen Thread in einem Forum erstellen, in dem dann eifrige "ichweiswas"-User dann die fertige Funktion (aus dem schon erwähnten Wust) heraussuchen und diese dann auf Nachfrage noch auf die Bedürfnisse des Threaderstellers passend umschreiben. Voila. Ziel erreicht.

Und WEHE, es wird auf die Hilfe oder noch schlimmer Google oder die Forensuche verwiesen....

Fazit:

Eine UDF ist so hinzunehmen wie sie ist. Wer sich berufen fühlt, "Gemeinsamkeiten" in den Aufrufkonventionen an die AutoIt-internen Funktionen anzugleichen/anzupassen, soll das tun und kann diese "Verbesserung" bei den DEV´s einreichen. Ich bin sicher, die sind froh, sollte sich jemand anderes diesem Thema annehmen....und würden das auch gerne in das nächste Update übernehmen

Hi,

du könntest versuchen, nur ein Script auf dieser Maschine laufen zu lassen und dieses (zur Not händisch) nur einem Core zuordnen. Dann eine zweite Instanz deines Scripts starten und auch diesem Core zuordnen. "Irgendwann" wird es dann zwangsläufig zäh werden.....Ich vermute, nach ca. 4-5 Instanzen. Woher ich das weiß? Ausprobiert, mehrmals, mit unterschiedlichen Scripten.

Das Interessante dabei ist, dass auf EINEM Core VIEL (!) mehr Instanzen flüssig laufen im Vergleich zu einem Mehrkern- oder sogar Mehrprozessorsystem.

Wie du vermutet hast, liegt das Problem liegt bei Windows. Der Scheduler hat bei einem Einkernprozessor nur die Zeitscheiben für eine Handvoll Threads zu verwalten, das macht der nebenbei im Schlaf...

Bei Multicore und Multiprozessorsystemen kommt hinzu, dass Windows exzessiv sog. Core-Hopping betreibt, und zwar umso mehr, je stärker die Prozessoren ausgelastet sind. Windows versucht "krampfhaft", die Last möglichst gleichmäßig zu verteilen. Das führt zum bei dir (und auch bei mir) festgestellten Wahnsinn, dass der Scheduler "am Anschlag" läuft, also so viel mit der Verwaltung der Zeitscheiben und des Core-Hoppings zu tun hat, dass die anderen Kerne teilweise wenig bis nichts zu tun haben und sogar in diverse Sleep-Modi fallen....

Die warten gewissermaßen darauf, wieder vom Scheduler "aktiviert" zu werden.

Wenn dann auch noch der Speicher (RAM) knapp wird, ist es ganz aus! Dann wird noch auf Teufel komm raus geswappt....

Nicht umsonst benötigt man "spezielle" Software, um aus den neuen 18- oder 24-Kernern auch Leistung herauszuholen.

Nichtsdesto trotz könntest du auch versuchen, einem "zäh" laufenden Script mit diversen Tools, beispielsweise dem ProcessExplorer von https://live.sysinternals.com , auf den Zahn zu fühlen. Ggf. "hängt" aber auch deine zu steuernde Software, Grund s.o.

Einen ersten Überblick würde ich mir mit dem Ressourcenmonitor aus dem Taskmanager verschaffen! Viel Spass dabei :o)

Zitat von Muecke

Die Stoppuhr wird im Vollbild Modus laufen und soll Zentriert auf dem Monitor angezeigt werden, wenn ich jedoch Fixe Koordinaten angebe dann ist das nur bei meiner Auflösung am Monitor zentriert und bei anderen Auflösungen dann nicht mehr :-(.

mit den Macros @DesktopHeight und @DesktopWidth erhälst du die Größe in Pixeln des aktuellen Desktops, also auf jedem Rechner individuell, auf dem dein Programm läuft.

Wenn deine GUI ja immer die gleiche Größe hat, sollte es kein Problem sein, das Fenster genau in der Mitte des Desktops zu zentrieren, egal wie die Bildschirmauflösung ist.

Hi,

schon mal in Scite reingeschaut?! Extras, Trace: Add Func Tracelines ...und was es sonst noch an Debuggingwerkzeugen dort gibt....

Zitat von fakeraol

Ich will nicht weiter stören. Kippt die irgendwo im Netz gefundenen RegExe in die Sammlung rein, bei Diskussionen nach dem Motto "Hab keine Ahnung, wozu die Slashes in den Ausdrücken sind, ABER ich hab mehr Postings als Du." bin ich falsch.

Ok! Ich bin auch dafür, dass du woanders trollst....

Du hast nicht begriffen, um was es in einem Forum geht.

Es ist dafür da, sachbezogen zu diskutieren. Nur eben an den dafür vorgesehenen Stellen. Und da liegt der Hase im Pfeffer!

Wenn du meinst, ein Forum ist dazu da ANDEREN (so wie z.B. DIR) "den Arm aus der Sonne zu legen", dann liegst DU falsch!

Wenn du möchtest, das dir jemand "den Arm aus der Sonne legt" aka erklärt "...wozu die Slashes in den Ausdrücken sind", dann frag einfach danach! Oder benutze Google....

Aber gehe nicht davon aus, dass jemand einen "Sammel"-Thread/Beitrag in einem Forum erstellt, um die Wissensdefizite zu diesem Thema der halben Weltbevölkerung zu kompensieren!

Ein Sammelthread ist dazu da, gezielt Informationen zur Verfügung zu stellen für Leute, die sich mit dem Thema AUSKENNEN!

Für alle anderen gibt es die Möglichkeit, einen neuen Thread zu erstellen und in diesem Fragen zu einem bestimmten Thema, bspw.: "...wozu die Slashes in den Ausdrücken sind...", zu stellen!

Zitat von fakeraol

Kippt die irgendwo im Netz gefundenen RegExe in die Sammlung rein,

GENAU DAFÜR ist ein Sammelthread da! Dafür, und für NICHTS ANDERES!

Zitat von autoiter

Es ist ja auch nicht so, dass es dort eine Shoutbox gäbe, deren letzten Beiträge als Benachrichtigung kämen.

Das soll ja wohl ein Witz sein? Ernsthaft, so langsam frag ich mich, wo ich hier gelandet bin!

Wenn IRGENDEIN User in IRGENDEINEM Thread, den ich gelesen habe (und nicht mal diese Seite aktiv habe) einen Post setzt, DANN bekomme ich umgehend per Popup eine Info "blablub hat im Thread xyz eine Antwort gepostet" MIT LINK DORTHIN!

Und hier wird diskutiert, ob das GLEICHE PROCEDERE mit einem Post in einer Shoutbox funktioniert?! Wir reden hier in einem Programmiererforum über eine Anwendung einer bereits bestehenden Funktion!

Wenn unsere (!) Forensoftware das nicht kann, dann mag das so sein, BRAUCHEN tu ich das nicht!

Genausowenig brauche ich aber eine Shoutbox, die mir bei FullHD-Auflösung eine komplette Bildschirmseite in jeder Threadansicht "stiehlt"...

Zitat von autoiter

Als ich hier recht frisch aktiv war, gab es ein Update, bei dem alle Anhänge erst einmal ein halbes Jahr weg waren! Seit dem letzten Update sind alle alten Links nicht mehr (direkt) brauchbar.

Ich habe letzte Woche erst viel Zeit damit verbracht, "alte" Threads zu finden und habe kapituliert...

Wenn du schreibst "nicht mehr (direkt) brauchbar", gibt es denn eine Möglichkeit, "indirekt" auf diese Threads zuzugreifen?

Zitat von autoiter

Dass jetzt mal seit zwei Tagen die Shoutbox nervt, ist doch fast nichts.

das ist ja eine Steilvorlage

Erinnert mich daran: https://de.wikiquote.org/wiki/Jean-Claude_Juncker das erste Zitat

Zitat von autoiter

PS: Ich hoffe, du bleibst uns noch eine ganze Weile erhalten.

schaumamal

Zitat von water

Wann fängst Du an?

Die Frage ist, wann höre ich (u.a. auch hier) auf....es wird zunehmend anstrengender....

Zitat von alpines

Ich hab von wbb nicht viel Ahnung, aber müsste man dafür nicht ein neues Plugin installieren, Rechte einstellen und sonst noch zurecht tweaken?

Erstmal alles zum alten bringen, dann können wir ja über neue Spielereien nachdenken.

Scheint wirklich extrem kompliziert zu sein...

Diese Nachrichten bekommt sogar mein Browser hin, s.u.

In anderen Foren macht man sich darüber gar keine Gedanken, man HAT das einfach!

Beispiel:

Der Inhalt kann nicht angezeigt werden, da du keine Berechtigung hast, diesen Inhalt zu sehen.

Hi,

du weißt, wo innerhalb der GUI dein GDI+-Objekt ist, und wie groß es ist.

Schau mal in der Hilfe nach GuiGetMsg(1), da erhälst du ein Array zurück mit allen Infos, die du brauchst, aktuelles Control, Mauszeigerkoordinaten uvm....

Zitat von autoBert

Die SB wird jetzt überall vorangestellt, nervt (unnnötiger INet-Volumen Verbrauch)

nervt ungeheuer!

Macht ein Benachrichtigungssystem, dass bei Bedarf die letzten 3 Zeilen der SB im unteren Bereich der aktuellen Bildschirmanzeige einblendet. So wie im "blauen" Forum, da bekommt man eine Nachricht "UserXY hat im ThreadAB geantwortet". Statt dieser Nachricht werden nur die 3 letzten Zeile SB für x Sekunden eingeblendet. So stell ich mir das vor :o)

Dann bin ich, egal auf welcher Website im Forum ich unterwegs bin, "im Bilde".

Was nützt eine SB die eine dreiviertel Bildschirmseite einnimmt obwohl "nix neues" darin dargestellt wird, wenn ich Threads lesen will und sowieso nach unten scrolle?!

Zitat von alpines

Sleep mal eine knappe Sekunde bevor du WinMove verwendest, eventuell versuchst du zu schnell das Fenster zu verschieben.

Du wartest nämlich nur solange bis das Fenster erstellt wurde, aber nicht sichtbar bzw. aktiv ist.

Generell ist ein fleißiges Einfügen vor Sleeps() in solchen Scripten sehr zu empfehlen, gerade bei Benutzung von Win10.

Wer meint, ein Fenster bzw. ein Control sei "online" , nur weil man es auf "dem Bildschirm" sieht, der liegt FALSCH!

Wenn die Message-queues von Windows geflutet werden, dann ist jede Anwendung/Fenster/Control froh, wenn überhaupt Nachrichten zeitnah verarbeitet werden.

Ich hatte nach Umstellung auf Win10 bei mehreren Automatisierungsscripten sowohl bei Netzwerkanwendungen als auch auf lokalen Maschinen sporadische "Hänger". Das macht dann bei etlichen hundert Zeilen Script (die bis dato einwandfrei liefen) keinen Spass....

Bei einigen Tests kam dann heraus, dass trotz erfolgreichem Winactive()/WinWaitActive() teilweise bis zu 1200ms (über eine Sekunde!!!) vergingen, bis ControlSend()/ControlClick()/ControlSetText() bzw. überhaupt alle "Steuerungen" funktionierten....

Einfügen von großzügig bemessenen Sleeps hat geholfen

Die Scripte laufen jetzt zwar eine Viertelstunde länger, aber dafür funktioniert wieder alles....

-->> NEVER RUN A CHANGING SYSTEM ! <<--

Zitat von Code-Jack

Für das Ausfaden müsste in einer Schleife jeder einzelne Pixel bei jedem Durchlauf ein kleines Stückchen dunkler gestellt werden, bis am Ende Schwarz erreicht ist, wie bei der von mir vorgeschlagenen Hintergrundfarbe.

Dafür bietet sich _GDIPlus_ImageAttributesSetColorMatrix() an, aber allein diese Funktion dauert aber (auf meinem Laptop) 32ms.....für die Aufgabe daher völlig ungeeignet, wie übrigens (mit Hinsicht auf hohe Geschwindigkeit) das ganze GDIPlus(mit PLUS!!!)-Gedöns!

Will man wirklich schnelle Grafik, bleibt einem (wie gehabt) GDI(OHNE Plus!), oder eine der anderen Bibliotheken.

Ggf. kommt man mit dem letzten Parameter von BitBlt() weiter, da hänge ich mich mal rein, ansonsten schreibt man da schnell was in ASM

Hi,

schönes Projekt!

Zitat von o2candoo

- Warum läuft das Programm schneller, wenn die Maus bewegt wird?

Weil du den sog. "Message"-Modus nutzt, statt den "Event"-Modus.

In der Funktion GuiGetMsg() ist eine Abfrage implementiert, welche dafür sorgt, dass bei "länger" ausbleibenden Eingaben (Maus, Tastatur, usw.) die Prozessorlast minimiert wird. Das hat bei GUI´s Vorteile, die auf User-Interaktionen warten, also Buttonklicks usw., aber eher wenig Berechnungen durchführen.

Um nur auf Events zu reagieren, also die volle Prozessorleistung an das Programm zu übergeben, nutzt man den GUIOnEventMode

Zitat von o2candoo

Ich werde dann Updates mit weiteren Features Posten und bin auch dann gespannt und offen für Verbesserungsvorschläge

Na, dann fang ich mal an......

- Farbe gehört ins Spiel! Am Besten Farbverläufe.....

- Interaktionen kommen immer gut, indem bspw. der User mit der Maus ins Bild klickert und dort dann eine Reaktion auslöst...

- Die Funktion ist schon recht schnell "fertig". Mir würde es gefallen, dass man noch einen Winkel festlegen könnte, um den das fertige Muster dann mehrfach gedreht werden würde. Letztendlich könnte man damit wunderschöne Mandalas kreieren.

Zitat von Mars

Das ASM berechnet Dif = ABS(R1 - R2) + ABS(G1 - G2) + ABS(B1 - B2) und summiert das über alle Pixel. Daher kann die Maximalabweichung 3*255=765/Pixel auch nicht überschreiten. Auf eine Gewichtung wurde bewusst verzichtet, ansonsten würde man eine Art "Grauwert" vergleichen und die "Farbe" würde zu wenig berücksichtigt.

Ja, genau so hatte ich das auch gemeint. "Mehr Grün" im Pixel sollte auch genau so ersetzt werden.

Zitat von Mars

Komprimieren wäre hiermit auch möglich

Damit hatte ich mich schon im Deskstream ausführlich beschäftigt. Das dort beherrschende Limit ist ja die Übertragung der imho lokal schon recht gut und schnell komprimierten Bilder übers Netz.

Mir persönlich reicht diese Geschwindigkeit aus, für Video in 800x600 mit >20fps um mal schnell auf nem anderen Rechner zu gucken was da vor sich geht ist das i.o.

Um die zu übertragenden Datenmengen einzustampfen hatte ich mir auch schon einen "Pool" von verwendeten 2x2 (3x3 oder 4x4) großen Pixelblöcken vorgestellt,der dynamisch bei bspw. jedem 10. übertragenen Frame neu berechnet wird. Da sowohl Sender als auch Empfänger als Grundlage die gleichen Bilderverwenden, wäre auch ein Abgleich übers Netz obsolet, lediglich bei einer Übertragungsstörung müssten beide "neu" starten.

Man würde dann nicht mehr die reinen Pixeldaten übertragen, sondern lediglich die Adressen der Pixelblöcke. Eine Verschlüsselung würde sich somit komplett einsparen lassen.....

Was wirklich gut klappt sind Portraits. Die würde ich aber auch nicht aus einer Landschaftsaufnahme erstellen lassen.

Ähnlich funktionieren übrigens die gängigen Kompressionsverfahren bei Bildern. Dort werden auch "ähnliche" Strukturen bzw. Bildbereiche gesucht und ersetzt .

Btw., ich hab deinen Assemblercode nur überflogen, ist es so, dass du die durchschnittliche "Farbe" von zwei zu vergleichenden Pixeln verwendest?

Ggf. könnte man die "Pixel" zum Vergleich auch 3x um 90° drehen. ich bin sicher, da ist noch einiges an Potenzial vorhanden.

Gut geworden!

Bei "Mid" kommen schon sehr gute Ergebnisse raus!

//EDIT

...bei den beiden Beispielbildern^^

Ich habe das Ganze mal mit "echten" Fotos wie bei meinen bisherigen Tests durchlaufen lassen, da wird auch bei Pixelgrößen von 8 das Ergebnis nur bei "Max" halbwegs brauchbar....

so müsste das passen...

Bei Little Endian dreht sich die Bytefolge um, man schreibt die Bytes also umgekehrt in eine 8 Byte große Bytestruct, erstellt an deren Adresse eine Doublestruct (auch 8 Bytes groß) und liest diese aus^^

;aligncomment=50
$f = "0000270A" & _                                ;0
        "00000000" & _                             ;4
        "00000000" & _                             ;8
        "00000000" & _                             ;12
        "00000000" & _                             ;16
        "00000000" & _                             ;20
        "0000006A" & _                             ;24
        "E8030000" & _                             ;28 1000
        "01000000" & _                             ;32 shape
        "128A48A3B7911741" & _                     ;36 xmin
        "0A495F25BD385641" & _                     ;44
        "17EA5B0BD1971741" & _                     ;52
        "005FF22AF1385641" & _                     ;60
        "0000000000000000" & _                     ;68
        "0000000000000000" & _                     ;76
        "0000000000000000" & _                     ;84
        "0000000000000000" & _                     ;92
        "000000010000000A01000000128A48A3B7911741005FF22AF1385641000000020000000A0100000014535860659517416583C9ABE0385641000000030000000A0100000048E8DC50099417418420CE2FCC385641000000040000000A0100000017EA5B0B9994"


For $i = 1 To 56 Step +8

    $f2 = StringMid($f, $i, 8)
    ConsoleWrite(Dec($f2) & @CRLF)

Next
ConsoleWrite("********" & @CRLF)




;integer
For $i = 57 To 72 Step +8
    $f2 = StringMid($f, $i + 6, 2) & StringMid($f, $i + 4, 2) & StringMid($f, $i + 2, 2) & StringMid($f, $i + 0, 2) ;Endianess umkehren
    ConsoleWrite(Dec($f2) & @CRLF)
Next

;double
$struct_byte = DllStructCreate("ubyte[8]")         ;Double ist 8 Bytes lang
$struct_double = DllStructCreate("double", DllStructGetPtr($struct_byte)) ;Double ist 8 Bytes lang, an der adresse der 8 einzelnen Bytes
For $i = 73 To 185 Step +16
    $f2 = StringMid($f, $i, 16)
    For $x = 0 To 7
        $byte = ("0x" & StringMid($f2, $x * 2 + 1, 2))
        DllStructSetData($struct_byte, 1, $byte, $x + 1)
        ;$test = DllStructGetData($struct_byte, 1)
    Next

    $double = DllStructGetData($struct_double, 1)
    ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $double = ' & $double & @CRLF & '>Error code: ' & @error & @CRLF) ;### Debug Console

Next

//EDIT

Da würde sich eine Funktion lohnen, die Anhand der übergebenen Bytes, des Typs und der Endianess den Rückgabewert ermittelt...

Habe gerade mal die PDF durchgeblättert, es sieht so aus, als ob alle Daten bis auf die ersten Werte (die sind in Big Endian) des Headers in Little Endian interpretiert werden müssen

Hi,

und wo ist jetzt das Problem?

Zitat von Kizum

von 9994 bis 106 ist auch alles korrekt

Auch danach ist alles "korrekt" es ändert sich lediglich die sog. "Endianess". Schau mal HIER, ob du damit weiter kommst

Zitat von Mars

damit sollten die Resultätbilder weniger störende "offensichtlich falsche" Rechtecke mehr haben.

Imho ist das Problem nicht das "offensichtlich falsche" Pixel, sondern das "offensichtlich falsche" Pixel mitten im Bild!

Gerade bei deinem Beispiel hat man reinweiße Pixel MITTEN IM BILD, bzw. mitten in den schwarzen bzw. dunklen Flächen! Das stört nicht nur, sondern vermurkst das komplette Ergebnis!

Hat man diese "falschen" Pixel am Rand, kann man diesen ggf abschneiden und hat trotzdem noch ein ansehnliches Ergebnis.

Oder man "erkennt" die "offensichtlich falschen" Pixel und wählt nur für diese noch mal aus den ursprünglichen Pixeln aus. Da kann man ja eine Schwelle festlegen, bspw. die letzten 10% "schlechter" Pixel einfach weglassen. Das würde auch verhindern, dass bei großen einfarbigen Flächen die schon angesprochenen unerwünschten Muster entstehen.