1. Dashboard
  2. Mitglieder
    1. Letzte Aktivitäten
    2. Benutzer online
    3. Team
    4. Mitgliedersuche
  3. Forenregeln
  4. Forum
    1. Unerledigte Themen
  • Anmelden
  • Registrieren
  • Suche
Alles
  • Alles
  • Artikel
  • Seiten
  • Forum
  • Erweiterte Suche
  1. AutoIt.de - Das deutschsprachige Forum.
  2. Mitglieder
  3. Yjuq

Beiträge von Yjuq

  • AutoIt-Object -- wie könnte AutoIt in OOP-Syntax aussehen

    • Yjuq
    • 8. August 2017 um 16:21

    Ja, kann man.

  • Genial einfaches Tool zur Web Recherche - Smartclip

    • Yjuq
    • 7. August 2017 um 01:47
    Zitat von Tuxedo

    [...] Inwiefern macht dich mein Avatar irre, im positiven oder im negativen Sinne? Ich finde ihn geil, hatte ich noch irgendwo in meinem Humorbilder-Archiv.

    Dein Profilbild macht mich im negativen Sinne irre. Es wirkt auf mich wie ein kompletter Widerspruch in sich selber der zugleich aber natürlich und selbstverständlich wirkt. Und genau das regt mich dabei so extrem auf... Hätte nie gedacht dass ein vermeintlich harmloses Bild solche Gefühle in mich auslöst...

    Wie erkläre ich das denn nun am besten? Also, die Abbildung des Bildes ist erst einmal unnatürlich. Eine Kreuzung zwischen einen Hund und einen Menschen ist absolut unnormal. Jedoch passen die Gesichtszüge (Augen / Stirn / Mund / Gesichtsausdruck) so gut zum Hunde Körper dass das Bild in sich natürlich wirkt. So als ob der Hund, wie er abgebildet ist, schon immer dieses Gesicht genau so hatte. Und genau dieser Widerspruch lässt mein Blut wallen und gleichzeitig erschauern. Aber das liegt eher an meiner abnormalen Betrachtungsweise der Dinge.

    Das Bild ist für mich genial und auch erschreckend zugleich. Und genau das treibt mich in die Irre weil ich nicht eindeutig weiß was ich davon halten soll...

    Um mal deine Frage zu beantworten, muss dich aber nicht weiter stören. x)

    ---

    €dit:
    Außerdem mag ich die Vorstellung nicht, dass mich ein Hund mit solch einem Gesichtsausdruck anschaut...

  • DllStructGetData durch Punkt-Notation ersetzen ein Risiko?

    • Yjuq
    • 6. August 2017 um 22:07

    Ich hab bisher noch keine Probleme damit gehabt und ich hab AutoIt schon für viele Sachen missbraucht wofür es nie ausgelegt war. Mach dir da mal kein Kopf drum :)

  • Genial einfaches Tool zur Web Recherche - Smartclip

    • Yjuq
    • 6. August 2017 um 20:46

    Gibt es denn einen bestimmten Grund warum du den Systemcursor nicht verändern willst? Das geht immer noch am einfachsten:

    [autoit]

    #include <WinAPIRes.au3>

    [/autoit][autoit][/autoit][autoit]

    Local $hPrev = _WinAPI_CopyCursor(_WinAPI_LoadCursor(0, 32512))

    [/autoit][autoit][/autoit][autoit]

    _WinAPI_SetSystemCursor(_WinAPI_LoadCursorFromFile(StringRegExp(@AutoItExe, ".*\\", 1)[0] & 'Examples\Helpfile\Extras\Lens.cur'), 32512)
    Sleep(5000)
    _WinAPI_SetSystemCursor($hPrev, 32512)

    [/autoit]

    Alternativ kannst du via GDI dein Image an die Mausposition zeichnen. Der Systemcursor ist aber dann immer noch sichtbar!

    PS: Dein Profilbild macht mich irre...

  • PandaRunner Reworked - Ein Autoit Game

    • Yjuq
    • 6. August 2017 um 03:13
    Zitat von xSunLighTx3

    Hast du ein Beispiel, wie du das meinst? Verstehe das nicht wirklich. Wenn ich die Systemzeit theoretisch ändere, wäre das Spiel dann nicht schneller/langsamer als normal?

    Nehmen wir einmal an wir haben eine Spielfigur die wir bewegen können. Die Geschwindigkeit dieser Spielfigur beträgt pro Sekunde 40 Pixel. Sind also bei 0.25 Sekunden 10 Pixel und bei 0.125 Sekunden eben 5 Pixel. Ein Tick in dem Spiel wird alle 0.1 Sekunden ausgeführt. Pro Tick kann zufällig mit einer Wahrscheinlichkeit von 5% pro Tick ein Punkt spawnen die der Spieler einsammeln kann. Das Spiel läuft normalerweise mit einer unbegrenzten FPS. Also so viel, wie der Spieler aus seiner Hardware heraus holen kann. Nehmen wir als Beispiel 3 verschiedene PC. Einen schnellen mit einer FPS von 120, einen normalen mit 60 FPS und einen langsamen der nur 30 FPS schafft.

    Das ist die Ausgangssituation für ein sehr einfaches Beispiel. Betrachten wir einfach mal beide Varianten - Geschwindigkeit des Spielers an die FPS angepasst und einmal an die Zeit.

    FPS als Indikator für die Spieler Geschwindigkeit
    Du hast vorgeschlagen die FPS mit dem Speed zu koppeln. Gehen wir das mal für die einzelnen PCs durch. Da der Spieler pro Sekunde 40 Pixel zurück legen soll muss hier das Ergebnis eben die 40 für die Geschwindigkeit des Spielers heraus kommen. Als zweiten Parameter haben wir dann die FPS und die unbekannte Variable die du oben als Speed-Variable deklariert hast:

    Schneller PC (120 FPS) -> 120 * $iSpeed = 40 -> 40 / 120 = $Speed = 0.333
    Normaler PC (60 FPS) -> 60 * $iSpeed = 40 -> 40 / 60 = $Speed = 0.667
    Langsamer PC (30 FPS) -> 30 * $iSpeed = 40 -> 40 / 30 = $Speed = 1.333

    Diese Werte bedeuten dass die Spielfigur 0.33, 0.67 oder eben 1.33 Pixel pro angezeigten Frame sich bewegt. Pro Frame also den ausgerechneten Wert um diese Anzahl an Pixel um die Geschwindigkeit bei zu behalten. An sich keine schlechte Idee, allerdings hat dies einen Nachteil. Die Framerate eines Games ist niemals konstant da die Anweisungen, die an die GPU oder CPu gesendet werden unterschiedlich lange berechnet werden bzw. das Programm diese unterschiedlich lange reserviert. Da können schon mal gerne 121 FPS oder eben 119 FPS kommen. Auch wenn du die Framerate künstlich limitierst auf 60 FPS kann es vorkommen dass manchmal nur 59 FPS erreicht werden. Der Knackpunkt an der Geschichte ist nun, dass du eine unregelmäßige Bewegung erhälst. Manchmal läuft nämlich alles etwas schneller oder langsamer ab je nachdem wie schnell die Berechnungen von statten gehen.

    Gehen wir mal davon aus unser Normaler PC mit 60 FPS hat gerade ne gute Runde erwischt und schafft so um die 65 FPS gerade weil das Update im Hintergrund fertig ist. Bisher war die Geschwindigkeit des Spielers 1.5 Pixel pro Frame. Da sich die Framerate allerdings nun geändert hat muss der Wert nun angepasst werden: 40 / 65 = 0.615. Nun gibt es ein Problem:

    Du kannst im vorneherein nicht wissen dass plötzlich die Framerate sich erhöht hat da du diese ja nicht jeden Frame neu berechnest, sondern erst nach einer Sekunde und du die Frames bis dahin zählst. Das hat zur Folge dass du 5 Extra Frames hast wo sich die Figur von der vorherigen Berechnung 3.077 Pixel zu viel bewegt da plötzlich statt 60 FPS eben 65 geschafft wurde. Das bedeutet in dieser Sekunde hast du eine Strecke von 43.1 Pixeln zurück gelegt statt den 40 und die Spielfigur war schneller. Nach der Sekunde reguliert sich dass dann durch die Neuberechnung zwar, allerdings verlangsamt sich dann auch die Bewegung der Spielfigur pro Frame. Das fällt als Spieler dann auf wenn die Figur plötzlich quasi kurz "abbremst".

    Andersrum verhält es sich wenn die Framerate dann hinunter geht. Sagen wir von 60 FPS auf 55 FPS. 55 * 0.667 = 36.667 -> Die Figur ist 3.3 Pixel zu langsam. Hat also nicht die 40 Pixel in der Sekunde geschafft...

    Das kann im Spiel dann zu komischen "ruckler" führen. Ich schreibe dir bei Gelegenheit mal eine kleine Simulation um das zu verdeutlichen. :)


    Zeitangabe als Indikator für die Spieler Geschwindigkeit
    Generell nimmt man am Anfang jedes Schleifendurchlaufs (also vor den Berechnungen) den aktuellen Timestamp. Das macht man via TimerInit() in AutoIt. Das Konzept nennt sich Delta Timing und anhand einer gemessenen Zeit die korrekte Position des Spielers im derzeitigen Frame bestimmen. Unsere Figur soll sich pro Sekunde 40 Pixel weit bewegen. Nun wissen wir aber nicht wie viele Frames der PC schafft, kein Problem.

    Wir berechnen einfach die Zeitdifferenz zwischen jedem Frame indem wir schlichtweg einfach den alten Timestamp mit dem neuen vergleichen. Nehmen wir an wir haben folgende beide Timestamps:
    Alter: 0.00 Sekunden (Programmstart / erster Frame überhaupt)
    Neuer: 0.10 Sekunden (2. Frame)

    Wir haben unsere Sekunde und die Zeitdifferenz von 0.10 Sekunden zwischen den beiden Frames. Unsere Figur bewegt sich Pro Sekunde 40 Pixel, die Rechnung sieht folgendermaßen aus: 0.1 / 1 * 40 = 4. [(Neuer Timestamp - Alter Timestamp) / 1 Sekunde * Strecke]

    So können wir unsere Figur pro Frame um die momentan vergangene Zeit bewegen. Ob jetzt in einen Frame nur 2 Pixel oder gar 6 Pixel zurück gelegt werden fällt erst mal nicht auf da der Gesamteindruck für das menschliche Auge mehr stimmt. Zwar sind in der Praxis diese Werte nicht so extrem auseinander (Es sei denn man hat gerade einen sogenannten FPS Lagg - Der fällt immer auf und da kann man nicht viel machen :/) aber die Geschwindigkeit bleibt konstant und wirkt um einiges flüssiger.


    Am besten schreibe ich dazu einfach mal ein Programm was beide Situationen gut verdeutlicht. Dann dürfte gut erkenntlich werden was ich meine. :)


    €dit:
    Habe nun ein Beispielcode. Der Rote Kreis richtet sich nach der Methode die man eher bevorzugen sollte. Der blaue Kreis nach der FPS. Lass das mal 5 Minuten laufen und beobachte das mal genau. Der blaue Kreis wird sich irgendwann von der Position des roten Kreises weg bewegen.

    [autoit]

    ; ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +

    [/autoit][autoit][/autoit][autoit]

    #include <GDIPlus.au3>
    #include <GUIConstants.au3>
    Opt("GUIOnEventMode", 1)

    [/autoit][autoit][/autoit][autoit]

    Global $hGUI, $hGraphics, $hBitmap, $hBuffer, $hBrush, _
    $hTimer, $iCounter, $iXRed, $iXBlue, $iFPS

    [/autoit][autoit][/autoit][autoit]

    ; ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +

    [/autoit][autoit][/autoit][autoit]

    $hGUI = GUICreate("FPS: 0", 500, 200)
    GUISetOnEvent($GUI_EVENT_CLOSE, GUI_EVENT_CLOSE)
    GUISetState()

    [/autoit][autoit][/autoit][autoit]

    ; GDI+ Gedönse
    _GDIPlus_Startup()
    $hGraphics = _GDIPlus_GraphicsCreateFromHWND($hGUI)
    $hBitmap = _GDIPlus_BitmapCreateFromGraphics(500, 200, $hGraphics)
    $hBuffer = _GDIPlus_ImageGetGraphicsContext($hBitmap)
    $hBrushRed = _GDIPlus_BrushCreateSolid(0xffff0000)
    $hBrushBlue = _GDIPlus_BrushCreateSolid(0xff0000ff)

    [/autoit][autoit][/autoit][autoit]

    ; Start FPS ~ So gegen 40 FPS maybe? Mal raten...
    $iFPS = 40

    [/autoit][autoit][/autoit][autoit]

    ; ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +

    [/autoit][autoit][/autoit][autoit]

    $hTimer = TimerInit()

    [/autoit][autoit][/autoit][autoit]

    While _RndLaggs()
    ; FPS Anzeige:
    If TimerDiff($hTimer) >= 1000 Then
    $iFPS = $iCounter
    WinSetTitle($hGUI, "", "FPS: " & $iFPS)
    $iCounter = 0
    $hTimer = TimerInit()
    EndIf

    [/autoit][autoit][/autoit][autoit]

    ; Zeichne die Kreise + Indikator:
    _GDIPlus_GraphicsClear($hBuffer, 0xffffffff)
    _GDIPlus_GraphicsFillEllipse($hBuffer, $iXRed, 40, 40, 40, $hBrushRed)
    _GDIPlus_GraphicsFillEllipse($hBuffer, $iXBlue, 120, 40, 40, $hBrushBlue)
    _GDIPlus_GraphicsDrawLine($hBuffer, $iXRed, 0, $iXRed, 200)
    _GDIPlus_GraphicsDrawLine($hBuffer, $iXRed + 40, 0, $iXRed + 40, 200)
    _GDIPlus_GraphicsDrawImage($hGraphics, $hBitmap, 0, 0)

    [/autoit][autoit][/autoit][autoit]

    ; Berechnet die nächste Position des Kreises:
    _Move()

    [/autoit][autoit][/autoit][autoit]

    ; Für FPS Anzeige
    $iCounter += 1
    WEnd

    [/autoit][autoit][/autoit][autoit]

    ; ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +

    [/autoit][autoit][/autoit][autoit]

    ; Diese Funktion soll lediglich die FPS Zahlen ein wenig manipulieren
    ; Hier könnten auch Spielberechnungen ablaufen etc... ^^
    Func _RndLaggs()
    Return Sleep(Random(10, 20, 1))
    EndFunc

    [/autoit][autoit][/autoit][autoit]

    ; Berechnung der Kreispositionen:
    Func _Move()
    Local Static $hTimestamp = TimerInit()

    [/autoit][autoit][/autoit][autoit]

    ; Berechnung via Delta Timing: (40 Pixel pro Sekunde)
    $iXRed += TimerDiff($hTimestamp) / 1000 * 40
    If $iXRed > 500 Then $iXRed = -40

    [/autoit][autoit][/autoit][autoit]

    ; Berechnung anhand des FPS Wertes: (40 Pixel PI mal Daumen :o)
    $iXBlue += 40 / $iFPS
    If $iXBlue > 500 Then $iXBlue = -40

    [/autoit][autoit][/autoit][autoit]

    $hTimestamp = TimerInit()
    EndFunc

    [/autoit][autoit][/autoit][autoit]

    ; ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +

    [/autoit][autoit][/autoit][autoit]

    ; Cleanup Code
    Func GUI_EVENT_CLOSE()
    _GDIPlus_BrushDispose($hBrushBlue)
    _GDIPlus_BrushDispose($hBrushRed)
    _GDIPlus_GraphicsDispose($hGraphics)
    _GDIPlus_BitmapDispose($hBitmap)
    _GDIPlus_GraphicsDispose($hGraphics)
    _GDIPlus_Shutdown()
    Exit
    EndFunc

    [/autoit][autoit][/autoit][autoit]

    ; ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +

    [/autoit]

    Und Nein, wenn du die Systemzeit änderst passiert rein gar nichts. Der Timestamp basiert darauf, wie viele Sekunden bisher seit dem 1. Januar 1970 vergangen ist. Selbst wenn du die Systemzeit änderst, die Hardware im PC hat dafür einen eigenen Zähler den du vom OS aus nicht verändern kannst.

  • PandaRunner Reworked - Ein Autoit Game

    • Yjuq
    • 5. August 2017 um 20:59
    Zitat von xSunLighTx3

    Das Problem hatte ich am Anfang auch. Ich habe das dann so gelöst, dass der Speed aller Aktionen mit den
    aktuellen FPS kalkuliert wird, sodass der Speed jede Sekunde auf die aktuelle FPS-Rate angepasst wird.

    Ach Herjee, man koppelt doch nicht die Geschwindigkeit eines Games an die FPS. Man koppelt diese immer an die tatsächliche Zeit um auch bei FPS Laggs / Verzögerungen in der Ausführung des Codes noch korrekt berechnen zu können.

  • Gamepad als maus ersatz

    • Yjuq
    • 4. August 2017 um 19:21

    Um was für ein Gamepad handelt es sich denn dabei? die XInput Bibliothek bietet eigentlich alles was man so braucht was Gamepad Inputs betrifft. Alles was im Layout eines XBox Controllers ist kann damit ohne Probleme angesteuert bzw. ausgelesen werden.

    https://msdn.microsoft.com/en-us/library/…3(v=vs.85).aspx

    ---

    Was ist eigentlich der Anwendungszweck dahinter? Es gibt nämlich bereits einige gute Softwares im Netz for Free womit sich so einiges machen lässt mit nen Gamepad. Ggf. ist es nicht nötig selber was zu schreiben.

  • Ping funktioniert in AutoIt nicht zuverlässig. In der CMD aber problemlos.

    • Yjuq
    • 29. Juni 2017 um 18:13
    Zitat von BLinz

    Ich finde das manchmal gar nicht so einfach dem Ding einen passenden, eindeutigen Namen zu geben ...

    Ich handhabe das meistens so, dass meine Funktionen einfach durchnummeriert werden:

    _0001()
    _0002()
    _0003()

    Nie wieder über lästige Funktionsnamen nachdenken!

  • Ping funktioniert in AutoIt nicht zuverlässig. In der CMD aber problemlos.

    • Yjuq
    • 27. Juni 2017 um 21:19

    Wie ist das Netzwerk denn aufgebaut und um was für eine Art Client reden wir denn hier? Ein paar mehr Informationen dazu könnten nicht schaden.

    Mal abgesehen davon macht es absolut keinen Sinn deine private IPv4-Adresse in den Screenshot halb zu verdecken. Die ist von Außen sowieso nicht ermittelbar (sprich: Keine Informationen herleitbar), deswegen ist es ja auch eine private IPv4-Adresse. Brauchst dir also gar nicht die Mühe machen. ^^

    €dit: Alternativ wenn die Ping Funktion weiterhin Probleme verursacht aber von der CMD aus keine Probleme gibt, dann führ via Run / RunWait den Ping von der Konsole aus.

  • DllCall('uxtheme.dll', 'INT64', 'SetThemeAppProperties', 'int', 0)

    • Yjuq
    • 27. Juni 2017 um 21:12
    Zitat von olfibits

    Dass er das will, war mir schon klar, aber nicht, wie genau. :) LG

    Das ergibt absolut keinen Sinn. ö.Ô
    Weder die Hervorhebung, um deinen Satz entsprechenden Ausdruck zu verleihen, noch dessen Inhalt bezogen auf den Kontext.

  • AutoIt Buch Projekt [THEMA BEENDET]

    • Yjuq
    • 25. Juni 2017 um 16:11

    An solch einen Buch verliert man schnell die Geduld. Du hast ja mein gescheitertes Projekt in Wikibooks gesehen, einfach nur weil ich damals auch schnell drauf los tippen wollte. Etwas für die Nachwelt hinterlassen und mein eigenes Verständnis vertiefen. Das Ende vom Lied war, dass ich nicht mal nach dem Thema Variablen die Lust gefunden habe, weiter daran zu arbeiten. Wozu auch? Es gab keine Nachfrage und ich war auch nicht sicher ob das überhaupt wer ließt. Ich hab es einfach nur für mich angefangen und es ist an der Motivation gescheitert.

    Wenn du wirklich ein Buch schreiben möchtest, dann solltest du dir das wirklich 3~4 mal gründlich überlegen ob und wie viel Zeit du darin investieren möchtest. Ich selber habe schon viele kleine Tutorials geschrieben, sei es für Programmiersprachen oder für irgendwelche Online Games. Du darfst weder Dank noch Anerkennung erwarten. Meist nörgeln die Leser noch gerne herum. Zumindest was meine Erfahrungen in den Bereich betrifft. ^^

    Ich will dich nicht entmutigen, aber übernimm dich da nicht. Ich weiß wovon ich rede, ich habe mir damals zu viel zugemutet.

  • Macro Creator für verschiedene USB Input Devices gesucht

    • Yjuq
    • 21. Juni 2017 um 20:34

    Hallo, ich suche eine Software welche es mir ermöglicht Makros für verschiedene Input Devices zu erstellen. Der Sinn dahinter ist, dass ich ein externes Numpad neben meiner Tastatur habe und ich auf diesen nun gerne Makros legen würde. Im Prinzip habe ich auch schon eine passende Software gefunden die diese Anforderung gerecht wird: HID Macros ( http://www.hidmacros.eu/ )

    Leider ist es so, dass das Programm keine verschiedene Profile unterstützt wodurch es unbrauchbar für mich wird. Kennt jemand zufällig ein ähnliches Programm welches noch gewartet wird? Ggf. habe ich nichts dagegen auch selber ein Programm zu entwickeln. Hat vielleicht jemand von euch schon mal ein Hardware Gerät von AutoIt angesprochen und Input entgegen genommen? Gibt es da vielleicht eine Art Device Hook in der WinAPI? Hat jemand Erfahrungen damit in irgend einer Weise? Onkel Google gab mir nur spärlich Informationen aus, die ich direkt verwerten konnte.

    Also, kennt jemand eine Software oder hat eventuell Informationen wie man sowas selber realisieren könnte (Als Anstoß - Finde da kein Anfang :/)

    Mit freundlichen Grüßen
    Make :)

  • Autoit Spiel (Logik)

    • Yjuq
    • 7. Oktober 2016 um 23:28

    Mein Ordner ist komplett leer bis auf das Skript, daher verwundert mich das ja o.o

  • Autoit Spiel (Logik)

    • Yjuq
    • 7. Oktober 2016 um 21:42

    Mal ne doofe Frage, wo nimmt er die Bilder her o,O

  • Hooks - WM_KEYUP verschlucken?

    • Yjuq
    • 2. Oktober 2016 um 19:39

    Hallo, ich würde gerne die WM_KEYUP Message auf einer bestimmten Taste komplett für das System verschlucken. Es soll also simuliert werden dass die Taste weiterhin gedrückt ist obwohl ich sie bereits losgelassen habe. Beim erneuten Drücken soll dann die WM_KEYUP Message wieder durchgelassen werden damit die Taste wieder "gelöst" werden kann. Ich hoffe es ist verständlich wie ich das meine.

    Im folgendem Skript habe ich versucht mit Hooks zu arbeiten, jedoch scheint dies nicht ganz zu klappen. Die Versuchstaste ist hier das "F":

    [autoit]

    #Region ;**** Directives created by AutoIt3Wrapper_GUI ****
    #AutoIt3Wrapper_Icon=C:\Program Files (x86)\AutoIt3\Icons\MyAutoIt3_Blue.ico
    #AutoIt3Wrapper_UseX64=n
    #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI ****
    ; ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +

    [/autoit][autoit][/autoit][autoit]

    #include <Misc.au3>
    #include <WinAPI.au3>
    #include <WinAPISys.au3>
    #include <WindowsConstants.au3>

    [/autoit][autoit][/autoit][autoit]

    Opt('TrayAutoPause', 0)
    Opt('TrayMenuMode', 1)

    [/autoit][autoit][/autoit][autoit]

    Global Const $g_sKey = _
    'ML8JC05IzZlvugyW' & _
    '9kKUesT6aBENBbVc' & _
    'dUJ56fFrHHkpp7zg' & _
    'oHJrD7mOslRw7Oeh'

    [/autoit][autoit][/autoit][autoit]

    _Singleton($g_sKey)

    [/autoit][autoit][/autoit][autoit]

    ; ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +

    [/autoit][autoit][/autoit][autoit]

    Global $g_idExit = TrayCreateItem('Exit')

    [/autoit][autoit][/autoit][autoit]

    ; ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +

    [/autoit][autoit][/autoit][autoit]

    Global $g_hLowLevelKeyboardProc = DllCallbackRegister(_LowLevelKeyboardProc, 'lresult', 'int;wparam;lparam')
    Global $g_hModuleHandle = _WinAPI_GetModuleHandle(0)
    Global $g_hHookKeyboard = _WinAPI_SetWindowsHookEx($WH_KEYBOARD_LL, DllCallbackGetPtr($g_hLowLevelKeyboardProc), $g_hModuleHandle)

    [/autoit][autoit][/autoit][autoit]

    ; ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +

    [/autoit][autoit][/autoit][autoit]

    While True
    Switch TrayGetMsg()
    Case $g_idExit
    _Exit()
    EndSwitch
    WEnd

    [/autoit][autoit][/autoit][autoit]

    ; ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +

    [/autoit][autoit][/autoit][autoit]

    Func _LowLevelKeyboardProc($nCode, $wParam, $lParam)
    Local Static $bRun = False
    Local $tKey = DllStructCreate($tagKBDLLHOOKSTRUCT, $lParam)
    If $nCode < 0 Then Return _WinAPI_CallNextHookEx($g_hHookKeyboard, $nCode, $wParam, $lParam)

    [/autoit][autoit][/autoit][autoit]

    If $wParam = $WM_KEYDOWN Then
    If $tKey.vkCode = 0x46 And Not $bRun Then
    $bRun = Not $bRun
    Return
    EndIf
    EndIf

    [/autoit][autoit][/autoit][autoit]

    If $wParam = $WM_KEYUP Then
    If $tKey.vkCode = 0x46 Then
    ConsoleWrite($bRun)
    If $bRun Then Return
    EndIf
    EndIf

    [/autoit][autoit][/autoit][autoit]

    Return _WinAPI_CallNextHookEx($g_hHookKeyboard, $nCode, $wParam, $lParam)
    EndFunc

    [/autoit][autoit][/autoit][autoit]

    ; ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +0

    [/autoit][autoit][/autoit][autoit]

    Func _Exit()
    _WinAPI_UnhookWindowsHookEx($g_hHookKeyboard)
    DllCallbackFree($g_hLowLevelKeyboardProc)
    Exit
    EndFunc

    [/autoit][autoit][/autoit][autoit]

    ; ++++++++++ +++++++++ ++++++++ +++++++ ++++++ +++++ ++++ +++ ++ +

    [/autoit]

    Hat jemand eine Idee für mich?

  • JavaFX in AutoIt? - Framework

    • Yjuq
    • 1. Oktober 2016 um 13:02

    Huch, was meinst du mit einschätzen? Ich war seit einem Jahr nicht mehr hier auf dem Board, geschweige denn dass ich irgendeine Software hier präsentiert habe. o.o
    Jetzt bin ich neugierig, welche Anhaltspunkte nimmst du denn dass du solch eine Aussage tätigen kannst? ^^

    Nun ja, aber gerne involviere ich dich in das Projekt. Jedoch solltest du (wenn du mir programmiertechnisch da helfen willst) dich mit FreeBASIC auskennen.
    Mit dieser Sprache entwickel ich die Bibliothek. Letztendlich wird es kein JavaFX Wrapper, sondern eine selbständig aufgesetzte Bibliothek die sich an dem JavaFX Framework orientiert.
    Wenn du Discord oder Teamspeak hast, können wir uns gerne mal darüber unterhalten. Ich bin gerade noch in der Planung und muss mir genau überlegen, wie die Bibliothek intern am besten alles verarbeitet
    damit sie:

    1. Leicht erweiterbar ist
    2. eine gute Performance bietet
    3. Leicht verständlich strukturiert ist

    Zudem brauche ich ein System, welches sich um das ganze Management intern kümmert. Da bin ich noch am grübeln. :)

  • MakeGUI - Grafische Benutzeroberflächen Bibliothek

    • Yjuq
    • 27. September 2016 um 17:32

    Hallo liebe Community, wie bereits angekündigt ( JavaFX in AutoIt? - Framework ) folgt nun hier der offizielle Projekt Thread wo über das Projekt diskutiert werden kann. Ich werde hier meine Entwicklung dokumentieren, mit euch Ideen besprechen und euch auf dem Laufenden halten. :)

    Die Planung:
    Ein größeres Projekt (besonders in diesem Umfang) muss gut geplant werden. Darum möchte ich euch erst einmal mitteilen was ich so im Hinterkopf habe und wie ich mir allgemein das Projekt vorstelle. Zuerst einmal möchte ich mich mit euch über das Konzept unterhalten (also wie wird die Bibliothek arbeiten bzw. welchen Funktionsumfang bietet diese).

    Das Konzept:
    Die Bibliothek soll als erstes ein Top-Level Window erzeugen, diese als Parent für alle Windows und Conrols darstellen soll, welche in ihr enthalten ist. In der JavaFX wird dieses Top-Level Window als "Stage" oder auch "Bühne" bezeichnet. Diese Bezeichnung möchte ich so beibehalten um eine Differenzierung zu den darunterliegenden Fenster zu erzeugen. Verknüpft an einer Stage ist immer eine Szene (Scene) worauf letztendlich die Controlls angeheftet werden. Diese Szene ist eher ein logischer Komponent, welcher als einfacher Container für die Controls darstellt. Diese Scenen können später einfach gewechselt werden. Dies ermöglicht es in einem einzelnen Fenster verschiedene Controls mit unterschiedlichen Funktionsweisen darzustellen. Ihr könnt euch das wie im Theater vorstellen. Ihr habt eure Bühne auf den die Schauspieler sind. Nach jedem Akt wird der Schauplatz (die Szene) gewechselt. Ich denke das ist ein sehr treffender Vergleich. Zudem können Scenen auch später anderen Container zugeordnet werden. Ob ihr von verschiedenen Szenen gebraucht machen werdet, ist dann euch überlassen. Jedoch möchte ich diese Möglichkeit nicht ausschließen. Zum Schluss kommen die 4 größere Aspekte die ihr mit einer Szene anstellen könnt.

    Zeichenfunktionen:
    Geplant sind Zeichenfunktionen. Zwar wird es möglich sein direkt via GDI+ oder GDI darauf zu zeichnen, aber die Bibliothek soll später eigene Zeichenfunktionen mitliefern die euch ermöglichen auch grafisch direkt darauf zuzugreifen. Womit die Grafikfunktionen nachher arbeiten (Ich vermute ich benutze dann Direct2D oder OpenGL dafür) steht noch nicht fest. Ob auch überhaupt welche gebraucht werden ist auch noch nicht klar. Jedoch können wir darüber diskutieren wenn es soweit ist, bis dato steht diese Komponente ziemlich weit hinten.

    Design:
    Eine andere Komponente soll das Design sein. Controls sollen später mithilfe einer Stylesheet mit CSS (oder evtl. einer eigenen Syntax) veränderbar sein. Diese Befehle sollen in externe Textdateien ausgelagert werden. Damit kann später das Design der GUI verändert werden, ohne den ausführbaren Code (also die Logik) zu beeinflussen. Ich möchte die Möglichkeit bieten das Design von der Logik zu trennen. Darunter fallen auch Dinge wie: Wie ordne ich meine Controls an bzw. wo plaziere ich diese?

    Layout:
    Das Layout soll eine logische Komponente werden. Das Layout sind eventuell besser unter dem Namen "Container" zu verstehen. Statt die Controls nach x und y Werten zu positionieren, sollen stattdessen Relationen genutzt werden. Darunter fällt beispielsweise ein Grid System welches eure Controls automatisch von der Größe und Position (je nach anforderung) positioniert und auch dynamisch verändert. Zu den einzelnen Containertypen komme ich allerdings noch.

    Controls:
    Der wohl wichtigste Punkt. Es wird Controls geben. Ja, Controls! Nicht nur standard Controls, sondern auch einige neue. Hier sind jedoch dann (wenn es so weit ist) Ideen gefordert. Das wichtigste wird aber das "CustomControl" werden, womit eigene Controls im nu erstellt werden können.

    Die Container:
    Die Container stellen eine logische Komponente dar, die euch helfen sollen eure Controls in der GUI anzuordnen. Dabei sollen sie Position und Größe automatisch berechnen, auch wenn das Fenster von der Größe verändert wird. Das Wichtigste ist allerdings, dass ihr auch verschiedene Containertypen kombinieren könnt und somit logische Sektionen für eure Controls erstellt. Verschiebt ihr beispielsweise ein Container, werden alle Controls in diesem Container mit verschoben.

    AnchorPane:
    Dieser Container ist ein einfacher Container. Ihr definiert die Abstände zu der GUI / Parent Container (Top, Bottom, Left, Right) und der Cntainer wird dort plaziert. Praktisch um Außenabstände zu definieren.

    FlowPane:
    Dieser Container ordnet eure Controls nacheinander an. Ihr könnt dazu enscheiden ob die Steuerelemente sich an der Oberkane oder Unterkante ausrichten.

    GridPane:
    Das GridPane ist eine Art Tabelle. Anstelle von Pixelgenauen Koordinaten könnt ihr stattdessen angeben, in welchen Zellen ihre eure Controls verpacken wollt. Die Größe des Tabelle wird dynamisch in der Bibliothek von selber bestimmt. Ihr könnt also ohne Probleme unendlich viele Zeilen und Spalten benutzen.

    HBox und VBox:
    Diese Container ermöglichen euch ein Einzeiliges bzw. Einspaltiges GridPane.

    Pane:
    Einfacher Container als Parent für eure Controls, um sie logisch als Einheit zusammenzuführen.

    StackPane:
    In diesem Container werden eure Controls / Container übereinander gelegt und erhalten eine Tiefe. Sagen wir, ihr habt ein Edit Control und wollt darauf einen Button legen, dann könnt ihr das mit diesem Container bewerkstelligen und festlegen, welches Control nun über welches angezeigt werden soll.


    Darüber hinaus wird es noch ein paar Container geben, die allerdings zusammen mit dem GridPane agieren. Das GridPane wird vermutlich der wichtigste Container werden.


    Aller Anfang ist schwer:
    Der erste Meilenstein den ich erreichen möchte sind die Container. Ich werde also zuerst eine funktionierende Bibliothek schreiben die GUIs erzeugt mit der Möglichkeit, die oben aufgelisteten Container zu nutzen. Anfangen werde ich mit einer allgemeinen Bibliothek die GUIs erzeugt und wo man die Standard Steuerelemente hinzufügen kann. Sie wird keine Vorteile gegenüber den GUI Funktionen besitzen. Danach füge ich die Container hinzu. So zumindest die Idee wie ich mit dem Projekt anfangen möchte.

    Gibt es bis hier Anmerkungen, Vorschläge oder Fragen? Wie gesagt, ich halte euch in diesem Thread auf dem Laufenden. :)

  • JavaFX in AutoIt? - Framework

    • Yjuq
    • 27. September 2016 um 16:20

    Das freut mich doch autoBert, letztenendes möchte ich das GUI Management schlichtweg vereinfachen. Das Hauptziel der Bibliothek soll sein einfach Professionelle GUIs aufzubauen, welche auch leicht erweiterbar sind. Nehmen wir mal ein Beispiel, ihr möchtet euren Programm ein weiteres Control hinzufügen, dafür müsstet ihr jedes andere Control verschieben, was dort im Weg steht. Soll die Bibliothek für euch erledigen, dynamisch versteht sich.

    Oder auch eigene Controls entwickeln. Die Bibliothek soll später die Möglichkeit bieten möglichst einfach eigene Controls zu erstellen welche dann genutzt werden können. Auch das Design der GUI soll später vom Code getrennt werden. Das heißt dass ihr (wie oben gezeigt mit CSS) das Design von Steuerelementen mit einer externen Datei verändern könnt, so habt ihr auch gestalterische Freiheiten.

    Es gibt vieles was ich da im Hinterkopf habe und hier noch nicht geäußert habe. Das Potential entgegen den normalen GUI Funktionen soll sich erst heraus kristallisieren, wenn es soweit ist. Bis dato muss ich erst mal eine ordentliche Basis schaffen. Aber erste Ideen erläutere ich nachher noch. :)

    Und je mehr die Biblithek in der Entwicklung testen, umso schneller komme ich voran und kann Fehler vorbeugen. Ich bin mal gespant wie lange das dauert. potentiell habe ich 1 1/2 Jahre Zeit und werde das Projekt auch fertigstellen.

  • JavaFX in AutoIt? - Framework

    • Yjuq
    • 27. September 2016 um 15:50

    Okey, ich habe mich dazu entschieden das Projekt nun umzusetzen. Nach den Beiträgen hier und nochmaligen Überlegung bin ich der Meinung, dass es sich lohnt und auch Anklang finden wird. Später wird es einen neuen Thread geben wo dann über das Projekt diskutiert werden kann, und ihr aktiv in die Entwicklung beisteuern könnt (sofern ihr mich unterstützen wollt). Das Projekt ist für EUCH, also währe es schön wenn da Ideen und Meinungen geäußert werden.

    Ich habe zudem folgendes beschlossen:
    - Ich werde nicht auf eine externe Bibliothek zugreifen, sondern das Alles von Grund auf aufsetzen. Alleine die WinAPI dient als Basis.
    - Die Bibliothek werde ich in FreeBASIC verfassen und dann via DLL Aufrufe verfügbar machen. So kann sie auch in anderen Sprachen genutzt werden.
    - Ich werde mit Handles und IDs arbeiten und die GUIs können auch mit der WinAPI angesteuert werden, jedoch fallen die GUI Funktionen flach wofür es eigene Funktionen geben wird.
    - Das Projekt wird Open Source unter folgender Lizenz: http://www.wtfpl.net/
    - Die Bibliothek wird MakeGUI heißen ;)

    Im Thread werde ich dann meine ersten Ideen und Vorstellungen detailliert posten, damit darüber diskutiert werden kann. Orientieren tue ich mich (vom Funktionsumfang) an der JavaFX Bibliothek, viele Bezeichnungen werde ich da auch fast 1 zu 1 übernehmen. Vor allem was Methodennamen usw. betreffen. Helfende Hände (egal welcher Hinsicht) sind immer gesehen. Sei es sich aktiv an Diskussionen zu beteiligen, oder aber selber mit zu programmieren. Aber zuerst zur Planung :)

    Gibt es Einwände?

  • JavaFX in AutoIt? - Framework

    • Yjuq
    • 26. September 2016 um 18:36

    Naja, wie ich das von der Syntax her löse (Richtung OOP-Style) oder aber einfach nur mit ID's arbeite kommt für beides auf's selbe Hinaus. Ich selber tendiere dazu eher das als OOP Syntax umzusetzen, da es meiner Meinung nach schöner zu lesen ist. Ein kleiner Vergleich:

    [autoit]

    $oGUI = _Lib_GUI()
    $oButton = _Lib_Button()
    $oButton.setText("Ich bin ein Button")
    $oGUI.add($oButton)

    [/autoit][autoit]

    $hGUI = _Lib_GUI()
    $idButton = _Lib_Button()
    _Lib_ButtonSetText($idButton, "Ich bin ein Button")
    _Lib_GUIAdd($hGUI, $idButton)

    [/autoit]

    So mal als kleiner Syntaxvergleich. Beides kommt auf's selbe hinaus...
    Mal schauen wie ich's mache, ansonsten kann man ja zum Schluss noch als Feature die andere Möglichkeit noch integrieren. Das sollte nicht das Problem sein.

    Wahrscheinlich wird's darauf hinaus laufen, dass die kompletten GUI Funktionen nicht mit der Bibliothek kompatible werden. Alternativ wird es dafür eigene Funktionen geben, sodass eine schnelle Umgewöhnung möglich sein wird. Ich möchte aber sowieso mit euch nochmal darüber diskutieren, was ihr euch so wünscht und dann Erwartungen daran habt. Immerhin soll die Bibliothek später die GUI Erstellung (ich rede von komplexeren GUI Layouts) wesentlich vereinfachen und euch so weit unterstützen wie nur möglich. Dabei natürlich aber den bisherigen gewohnten Freiraum weiterhin liefern. Was genau ich nun integriere, wie ich Dinge umsetze usw. hängt dann größtenteils von euch ab. Sofern ich das Projekt starte (wenn sich noch ein paar hier melden) werde ich sämtliches mit euch dann besprechen. Was ich mir vorstelle, womit ich anfange und was ihr haben wollt. Es wird eines meiner ersten größeren Projekte die ich meiner Community, die mir geholfen hat einen Start in die Programmierung zu finden, widmen werde.

Spenden

Jeder Euro hilft uns, Euch zu helfen.

Download

AutoIt Tutorial
AutoIt Buch
Onlinehilfe
AutoIt Entwickler
  1. Datenschutzerklärung
  2. Impressum
  3. Shoutbox-Archiv
Community-Software: WoltLab Suite™