Beiträge von BugFix

In beiden Fällen nutzt du "FileOpenDialog " mit entsprechenden Filtern.
Bei "Neu" wird die Datei erstellt, sofern nicht vorhanden unter Verwendung von Flag 8.

@DJ:
Dein angebrachter Link ist allerdings hoffnungslos überaltert und von der aktuellen Rechtssprechung (glücklicherweise) überholt. M$ wurde verdonnert die Installation des IE nur noch als Option anzubieten. Du mußt also der Installation des IE gesondert zustimmen. Sagst du 'Nein', wird er auch nicht installiert.
Ich weiß allerdings nicht, wie sich das auf die Windows-Update-Funktion auswirkt. Bis XP war ja zumindest ohne IE keine Nutzung der Update Funktion möglich. Bei Vista und Win7 weiß ich es nicht, da ich die nicht näher kenne.

Zitat von Oscar

Liegt das nun an AutoIt oder an Windows, dass dieser "falsche" Pfad ("c:\\test" bzw. "c:\\test.txt") trotzdem funktioniert?

Meines Erachtens ist Windows in diesem Punkt recht flexibel. Du kannst ja auch z.B. so addressieren: "C:/windows\config" - da stört sich Windows auch nicht dran.

Zitat von qixx

BugFix : Und wo wird jetzt genau aufgerufen, dass die Zelle gefärbt wird?

Schau mal in der Funktion WM_NOTIFY die Kommentare an
Kannst dort z.B. mit Switch-Case für mehrere Zellen Farbinfos hinterlegen. Aber nicht vergessen einen Else-Zweig für die Default-Färbung zu setzen.

Wenn du nur die Hintergrundfarbe (also nicht die Schriftfarbe und Schriftart) ändern möchtest geht es so am Einfachsten:

Falls du mehr formatieren möchtest, schau mal hier rein: ListView - SubItem einzeln färben/formatieren, Finale Version!

Achja - falls du SciTE in deutsch möchtest, kopiere die angehängte Datei in das Rootverzeichnis von SciTE.
Entferne dann die Endung ".txt" vom Dateinamen, habe ich nur angehängt um es hier hochladen zu können.

OK, hier die aktuelle Version.

Edit: Da war der Oscar schneller.

Ich kann keine sinnvolle Struktur erkennen. Du mußt doch wissen wieviel Dimensionen du brauchst. 8 sind es in deiner Darstellung nicht, sondern eher ein seltsamer Mix in einem 2D-Array.

Zitat von AspirinJunkie

Ich hoffe auf dieses Fazit können wir uns einvernehmlich einigen.

Das ist als Schlußwort absolut treffend. Ich habe meinen Startpost editiert und auch auf dieses Schlußwort verwiesen.
Danke an alle Beteiligten für die aufschlußreiche Diskussion.
Meine Großmutter hatte doch recht, wenn sie sagte: "Kannste alt werd'n, wie 'ne Kuh - lernste immer noch dazu."

Zitat von Dietmar

Bei
@ScripDir
müste man prüfen ob es auf ein \ endet.

Brauchst du nicht prüfen - die Makros enthalten, soweit ich weiß, niemals einen abschließenden Backslash.

Vielleicht hilft dir das zum Editieren: ListView - Editieren aller SubItems

Zitat von nuts

Aber wie macht ihr das dann z.B. mit einer aufwendigen Main GUI?

Ich deklariere dann eine Globale Variable (Array) und speichere darin alle erforderlichen Werte. Ist nur etwas mehr an Dokumentationsaufwand, damit man die Zuordnung auch vor Augen hat.

Leider nicht möglich. Mit Run wird nur der Dialog gestartet. Die Liste des Dialogs ist aber kein Standard-Control und kann nicht per Control-ID oder Class angesprochen werden.

Also, Protection.Property ist ReadOnly!
Es gibt wohl keinen direkten Weg per Skript das PW zu setzen. Vorstellbar wäre eine Variante mit Send/Controlsend/ControlClick. Mußt halt mal probieren, was da geht.

Zitat von Mike32

Könntest du mir noch netterweise kurz mitteilen, wie ich per Autoit beim Projekt das Passwort eingebe bzw. den Schutz temporär aufhebe und nachher wieder einschalte?

Also für das Workbook geht das (wenn ich mich recht erinnere) mit:

$oExcel.Workbooks.Open($sPath)
$oExcel.Workbooks.Unprotect('Passwort')

Aber wenn das Project PW-geschützt ist.. ich glaube, die Protection.Property ist ReadOnly.
Mal suchen, ob es da eine Lösungsmöglichkeit gibt.

Zitat von Mike32

Die gleiche Datei als Excel 97-2003 (.xls) abgespeichert und ich habe das beschriebene Problem. Kann es sein, dass die VBA-Struktur dann anders ist? - Und wenn ja, wie?

Das übersteigt mein Wissen in dem Bereich.
Aber falls es dir reicht, den normalen Makro-Dialog anzuzeigen - das geht so:

Const $xlDialogRun = 17
Local $oExcel, $sPath = 'Deine_Excel.xls'

$oExcel = ObjCreate('Excel.Application')
$oExcel.Visible = 1
$oExcel.Workbooks.Open($sPath)
$oExcel.Application.Dialogs($xlDialogRun).Show

Funktioniert bei mir tadellos. Laut MSDN dürfte die Excel-Version keine Rolle spielen. OS ist bei mir XPHome SP3.

Es ist etwas aufwändiger.
Ich habe mal das Excel-Object-Model auf MSDN durchforstet und bin zu dieser Lösung gekommen:

Const $vbext_ct_ClassModule = 2
Const $vbext_ct_Document = 100
Const $vbext_ct_StdModule = 1
Const $vbext_pk_Proc = 0

Local $sPath = 'Deine_Excel.xls'
Local $oExcel, $oBook, $oProj, $oComp, $Makro, $aMakro[1] = ['']

$oExcel = ObjCreate('Excel.Application')
$oExcel.Visible = 1
$oBook = $oExcel.Workbooks.Open($sPath)
$oProj = $oBook.VBProject
$oComp = $oProj.VBComponents

For $Komponente In $oComp
If $Komponente.Type = $vbext_ct_ClassModule Or $Komponente.Type = $vbext_ct_Document Or _
$Komponente.Type = $vbext_ct_StdModule Then
With $Komponente.CodeModule
For $i = 1 To .CountOfLines
If .ProcOfLine($i, $vbext_pk_Proc) > "" Then
$Makro = .ProcOfLine($i, $vbext_pk_Proc)
If $Makro <> $aMakro[UBound($aMakro)-1] Then
If $aMakro[UBound($aMakro)-1] <> '' Then ReDim $aMakro[UBound($aMakro)+1]
$aMakro[UBound($aMakro)-1] = $Makro
EndIf
EndIf
Next
EndWith
EndIf
Next
For $i = 0 To UBound($aMakro)-1
ConsoleWrite($aMakro[$i] & @CRLF)
Next

Edit: Kannst die Makros ja z.B. in einer ComboBox anzeigen und das vom User gewählte Makro so starten:

$oExcel.Application.Run('Makro_Name')

Zitat von woehlb

Kritisch dürfte in jedem Fall für das AutoIt-Skript eine Änderung der Bildschirmauflösung sein. Wie kritisch ist die Verwendung unterschiedlich großer Bildschirmfonds?

Das halte ich für unkritisch. Deine Zugriffskoordinaten müssen halt eine relative Berechnung unter Nutzung der Makros für Desktop -Breite/-Höhe beinhalten. Für die Toolbar erhältst du ja die Controlgröße und kannst anhand der Buttonanzahl die Breite der Einzelbutton berechnen.
Auch die verwendeten Fonts halte ich für nicht relevant. Wenn die Controlgröße sich relativ zum verwendeten Font ändert, so spielt das für dich keine Rolle, weil du in der Koordinatenadressierung die Controlgröße in der Berechnung dann sowieso einfließen läßt.

Zitat von stayawayknight

Du kannst den Code aber um einiges kürzen, wenn du Arrays verwendest!

Mag das meist der Fall sein - hier trifft es nicht unbedingt zu. Die Controls in Arrays zu packen führt zur Einsparung von nur einigen wenigen Skriptzeilen und würde aufgrund des Aufbaus nicht unbedingt die Lesbarkeit erhöhen.

Was ich empfehelen würde:
Eine GUI einsparen und Titel und Aktionen nach Bedarf zuordnen.

Die Spaltenbreitenzuordnung könnte man in einer Schleife lösen, bringt aber auch keine große Einsparung.

Eventuell überlegenswert, die INI-Struktur so anzupassen, dass sektionsweise gelesen wird. Dann hat man die Daten sofort im Array.

Eines meiner ersten Skripte war auch eine Artikelverwaltung. Kannst du dir ja mal anschauen. Der Code muß allerdings erst an die aktuelle AutoItversion angepaßt werden.