Beiträge von BugFix

Du kannst die Ränder zeichnen:

#include <GDIPlus.au3>
#include <GUIConstantsEx.au3>
#include <WindowsConstants.au3>

$hGUI = GUICreate('', 600, 400, -1, -1, $WS_POPUP)
GUISetBkColor(0xFF6F45)
$exit = GUICtrlCreateButton('Exit', 525, 365, 60, 20)
$hWnd = WinGetHandle($hGUI)
GUISetState()
_GDIPlus_Startup ()
$hGraphic = _GDIPlus_GraphicsCreateFromHWND ($hWnd)
$hBrush = _GDIPlus_BrushCreateSolid(0xFF1195FF)
_GDIPlus_GraphicsFillRect($hGraphic, 0, 0, 4, 400, $hBrush) ; links
_GDIPlus_GraphicsFillRect($hGraphic, 596, 0, 4, 400, $hBrush) ; rechts
_GDIPlus_GraphicsFillRect($hGraphic, 0, 0, 600, 4, $hBrush) ; oben
_GDIPlus_GraphicsFillRect($hGraphic, 0, 396, 600, 4, $hBrush) ; unten
Do
Until GUIGetMsg() = $exit
_GDIPlus_GraphicsDispose ($hGraphic)
_GDIPlus_BrushDispose ($hBrush)
_GDIPlus_Shutdown ()

Die Farbe für $hBrush wird angegeben: 0xAlpha R G B - setze für Alpha einfach FF und dahinter ganz normal der Hexfarbcode.

Grrrr, die Idee war gut.... aber: habe nicht bedacht, dass das Parent-Window keinen Popup-Style haben darf.
Mal überlegen, vielleicht fällt mir noch was ein.

@ zemkedesign: Das nützt ihm wenig, da es eine zusätzliche Verwaltung des GUI-Aufbaus erfordert. Er kann ja auf einer fix definierten Fläche keine variable Anzahl an Objekten erstellen. Beliebig vergrößern ließe sich das auch nicht, es müßte evtl. mit Tabs gearbeitet werden.
Daher mein Tipp mit dem ListView. Fixe Größe und alles paßt rein

Nimm eine Konstruktion aus Parent- und Child-Window.
Damit du frei gestalten kannst, bekommen beide POPUP-Style. Dann gestaltest du das Parent frei nach Bedarf und bettest das Child ein, sodass vom Parent nur die gewollten Bereiche sichtbar sind. Somit kannst du dort völlig frei eigene grafische Elemente, Ränder etc. platzieren.

Das Einfachste: Verwende ein ListView mit Checkbox-Style, dann ist es egal, wieviel Einträge du im Array hast.

Was stört dich an @SW_HIDE ? Speicherplatzsorgen?
Wenn du die GUI im weiteren Programm definitiv nicht mehr benötigst, kannst du sie, wie bereits in den vorigen Posts erwähnt, mit GUIDelete() "entsorgen".
Falls du sie aber nochmals benötigst, wäre das hochgradig schwachsinnig sie jedesmal neu zu erstellen.

Hi,
ich bin gerade am Ausprobieren der Versionen von Euch. Bei eukalyptus ist mir aber sofort ein Fehler aufgefallen:
Durch Verwendung des kurzen Strings in der Schleife bei ADD spart er schön Zeit ... aber der Speicherüberlauf geht verloren. Außerdem ist die Länge des Ergebnisstrings nicht passend.
Laßt mal in allen Euren Skripts folgende Aufgabe durchlaufen:

$BigInt_1 = _StringRepeat('9', 180)
$BigInt_2 = _StringRepeat('9', 90)

ConsoleWrite(_BigInt_Add($BigInt_1, $BigInt_2) & @CRLF)

Das Ergebnis muß 181 Stellen haben mit Überlauf bis zur ersten Position.

1000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000999999999999999999999999999999999999999999999999999999999999999999999999999999999999999998

Für die MUL gilt das analog. Das Ergebnis bei eukalyptus ist nur 222 Stellen lang. 180 9en mal 90 9en müssen aber logischerweise 180 +90 ==> also 270 Stellen werden.

999999999999999999999999999999999999999999999999999999999999999999999999999999999999999998999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001

Ich denke mal, da wird der Benchmarktest nicht allen Erfordernissen im geforderten Zahlenbereich bis 200 Stellen Länge gerecht.

Edit

Ich habe die vorangestellte Aufgabe mit den Versionen von eukalyptus, peethebee, Oscar und mir getestet. Außer bei eukalyptus wird überall das richtige Ergebnis geliefert.
@eukal: Na, wohl doch etwas überoptimiert?

Zitat von Amandil

Hallo liebe Community,
ich würde mich freuen wenn mir einer ein Skript schreiben könnte,

- Ich könnte dir vielleicht noch ein Mandeltörtchen backen...
Aber wie peethebee schon sagt: Es ist nicht schwer und wenn trotzdem Fragen auftauchen, helfen wir schon. Aber erst mal selber anfangen.

So, Abgabetermin ist rum.
Auch wenn ich nicht auf dem Podest lande, hier meine SpeedVariante (ca. 0,12 sec).

Zitat von Raupi

$Form1 =

Zitat von Raupi

WinMove($Form

Schau dir WinMove() an.

Du hast Fans ?! - Ich habe Schulden :wacko:

Nee, das geht ganz sicher nicht. Drum will ich ja mal schauen, was die DLL's so hergeben.

OK, hier ein Beispiel:

Zitat von Korby

Mit StrinEncrypt könnte ich doch aber nur die zugehörigen Werte verschlüsseln und nicht die ganze .INI, oder sehe ich das falsch?

Du könntest auch die gesamte Datei Ver-/Entschlüsseln. Dann mußt du die INI aber temporär speichern um sie dann "normal" zu lesen.

Die INI als Datei würde ich nicht verschlüsseln - sondern die eingetragenen Parameter (Sektionsnamen, Schlüssel, Werte).
Du kannst vom User das Passwort zum Entschlüsseln beim Programmstart anfordern und damit die Daten aus der INI entschlüsseln.
Wenn neue Daten in die INI geschrieben werden müssen machst du das wiederum durch Interaktion mit dem User.
Natürlich könntest du auch das Paßwort im Skript hinterlegen - aber was nützt ein Tresor, wenn der Schlüssel daneben hängt?

Hi sc4ry,
ich kann dir zumindest schonmal sagen, dass SSL-Verschlüsselung möglich ist. Du benötigst dazu in jedem Fall eine zusätzliche DLL für den Verschlüsselungsdienst. Für mIRC habe ich etwas gefunden - ich werde jetzt mal testen, ob ich das aufbröseln kann und für den eigenen Client nutzen kann. Falls du selber rumprobieren möchtest - hier die Info: IRC mit SSL

Zitat von Lenny

Nur noch die Fensterleiste muss noch ab

Diese Maße kannst du hiermit: _GetSystemMetrics (kpl. in einem Aufruf) ermitteln.

Zitat von peethebee

Sobald man Sachen wie 4/3 direkt berechnet, muss man einen Genauigkeitsverlust befürchten (bzw. hat ih faktisch). Eigentlich müsste man also Brüche verwalten und auch automatisch kürzen...

peethebee

"Dezimal" betrachtet stimme ich dir zu - aber wenn Brüche vorhanden sind, würde ich auch mit Brüchen rechnen und nur das Endergebnis dezimal ausgeben. Ich brauche ja bei der Betrachtung von Brüchen nicht nach sinnvollen Erweiterungen (also kgV / ggT) suchen. Schließlich brauch ich nicht von Hand rechnen. Also ist der gemeinsame Nenner einfach das Produkt der Nenner, Zähler entsprechend erweitern und fertig . Sofern die Brüche nicht in Dimensionen liegen, die den Zahlenrahmen von AutoIt sprengen halte ich diesen Weg für praktikabel.

Hi,
mal ein wenig Gedankengut von mir dazu :D.
Das Problem bei der Berechnung von Aufgaben, deren Form (Rechenart) und Inhalt ich vorab nicht kenne, ist hauptsächlich die Berücksichtigung der Vorrangsregeln.
Hier ist es sicher sinnvoll mit Taschenrechner-Logik zu arbeiten - d.h. nach jedem neu eingegebenen Element (Ziffer, Operator, Klammer) muß die Vorrangigkeit einzelner Operationen im Gesamtoperationsstring neu überprüft werden. Ob statt einer Ziffer auch eine Variable enthalten ist, ist für die Basis der Operation nebensächlich.
Wenn die Basis steht kann ich auch rechnen und brauch nicht näherungsweise Ergebnisse vergleichen. (Natürlich sollte ich Divisionen durch Null abfangen )
Aber ist auf jedenfall ein interessantes Projekt. Vielleicht werde ich mich auch mal etwas darin vertiefen.
Wünsche noch viel Erfolg.