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:
#Include <GuiConstantsEx.au3>
#Include <GuiListView.au3>
#Include <ListViewConstants.au3>
#Include <StructureConstants.au3>
#Include <WindowsConstants.au3>
$GUI = GUICreate("Listview Zelle/Spalte färben", 400, 300)
[/autoit] [autoit][/autoit] [autoit]$cListView = GUICtrlCreateListView("", 2, 2, 394, 268)
$hListView = GUICtrlGetHandle($cListView)
_GUICtrlListView_SetExtendedListViewStyle($hListView, BitOR($LVS_EX_GRIDLINES, $LVS_EX_FULLROWSELECT))
[/autoit] [autoit][/autoit] [autoit]_GUICtrlListView_InsertColumn($hListView, 0, "Column 1", 100)
_GUICtrlListView_InsertColumn($hListView, 1, "Column 2", 100)
_GUICtrlListView_InsertColumn($hListView, 2, "Column 3", 100)
For $i = 1 To 30
_GUICtrlListView_AddItem($hListView, "Row" & $i & ": Col 1", $i-1)
For $j = 1 To 2
_GUICtrlListView_AddSubItem ($hListView, $i-1, "Row" & $i & ": Col " & $j+1, $j)
Next
Next
GUIRegisterMsg($WM_NOTIFY, "WM_NOTIFY")
GUISetState()
Do
Until GUIGetMsg() = $GUI_EVENT_CLOSE
Func WM_NOTIFY($hWnd, $Msg, $wParam, $lParam)
Local $hWndFrom, $iIDFrom, $iCode, $tNMHDR
$tNMHDR = DllStructCreate($tagNMHDR, $lParam)
$hWndFrom = HWnd(DllStructGetData($tNMHDR, "hWndFrom"))
$iIDFrom = DllStructGetData($tNMHDR, "IDFrom")
$iCode = DllStructGetData($tNMHDR, "Code")
Switch $hWndFrom
Case $hListView
Switch $iCode
Case $NM_CUSTOMDRAW
If Not _GUICtrlListView_GetViewDetails($hWndFrom) Then Return $GUI_RUNDEFMSG
Local $tCustDraw = DllStructCreate($tagNMLVCUSTOMDRAW, $lParam)
Local $iDrawStage, $iItem, $iSubitem, $hDC, $iColor
$iDrawStage = DllStructGetData($tCustDraw, 'dwDrawStage')
Switch $iDrawStage
Case $CDDS_ITEMPREPAINT
Return $CDRF_NOTIFYSUBITEMDRAW
Case BitOR($CDDS_ITEMPREPAINT, $CDDS_SUBITEM)
$iItem = DllStructGetData($tCustDraw, 'dwItemSpec')
$iSubitem = DllStructGetData($tCustDraw, 'iSubItem')
$iColor = RGB2BGR(0xFFFF00) ; Hintergrundfarbe für Spalte
$iColDefault = RGB2BGR(0xFFFFFF) ; Standardfarbe (weiß)
If $iItem = 1 And $iSubitem = 1 Then ; Hier Item (Zeile) und SubItem (Spalte) festlegen (für Färbung Einzelzelle)
;~ If $iSubitem = 1 Then ; Hier SubItem (Spalte) festlegen (für Färbung ganze Spalte)
DllStructSetData($tCustDraw, 'clrTextBk', $iColor)
Else
DllStructSetData($tCustDraw, 'clrTextBk', $iColDefault)
EndIf
Return $CDRF_NEWFONT
EndSwitch
EndSwitch
EndSwitch
Return $GUI_RUNDEFMSG
EndFunc ;==>WM_NOTIFY
Func RGB2BGR($iColor)
Return BitAND(BitShift(String(Binary($iColor)), 8), 0xFFFFFF)
EndFunc
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.
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."
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
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.
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.
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:
[autoit]$oExcel.Application.Run('Makro_Name')
[/autoit]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.
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.
;~ #Region ### START Koda GUI section ### Form= ===> Identisch zu Form_Add, einfach Umbenennen bei Bedarf und und nach Titel die Aktionen zuordnen (Add oder Bearb.)
;~ $Form_bearb = GUICreate("Bearbeiten", 196, 231, 192, 124)
;~ $Input1_bearb = GUICtrlCreateInput("", 36, 24, 121, 21)
;~ $Input2_bearb = GUICtrlCreateInput("", 36, 72, 121, 21)
;~ $Input3_bearb = GUICtrlCreateInput("", 36, 120, 121, 21)
;~ $Input4_bearb = GUICtrlCreateInput("", 36, 165, 121, 21)
;~ $Button1_bearb = GUICtrlCreateButton("Ok", 36, 192, 43, 25, $WS_GROUP)
;~ $Button2_bearb = GUICtrlCreateButton("Cancel", 84, 192, 75, 25, $WS_GROUP)
;~ $Label1_bearb = GUICtrlCreateLabel("Artikelbeschreibung:", 36, 8, 100, 17)
;~ $Label2_bearb = GUICtrlCreateLabel("Anzahl verfügbare Artikel:", 36, 56, 125, 17)
;~ $Label3_bearb = GUICtrlCreateLabel("Anzahl verkaufte Artikel:", 36, 104, 119, 17)
;~ $Label4_bearb = GUICtrlCreateLabel("Interne Artikelnummer:", 36, 152, 109, 17)
;~ GUISetState(@SW_HIDE)
Die Spaltenbreitenzuordnung könnte man in einer Schleife lösen, bringt aber auch keine große Einsparung.
Local $aWidth[420,40,40,40,75]
For $i = 0 To 4
GUICtrlSendMsg(-1, $LVM_SETCOLUMNWIDTH, $i, $aWidth[$i])
Next
;~ GUICtrlSendMsg(-1, $LVM_SETCOLUMNWIDTH, 0, 420)
;~ GUICtrlSendMsg(-1, $LVM_SETCOLUMNWIDTH, 1, 40)
;~ GUICtrlSendMsg(-1, $LVM_SETCOLUMNWIDTH, 2, 40)
;~ GUICtrlSendMsg(-1, $LVM_SETCOLUMNWIDTH, 3, 40)
;~ GUICtrlSendMsg(-1, $LVM_SETCOLUMNWIDTH, 4, 75)
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.
Gibt es einen anderen Weg die Command-ID's der dynamischen Button zu ermitteln?
Ich habe das bei einer Anwendung ähnlich gehabt. Dort wurden auch interne ID vergeben, die per AutoIt nicht auslesbar und somit ansprechbar waren. Ich hatte das dann per Koordinatenberechnung auf Basis der Toolbar-Koords gelöst. (Basisdaten Toolbar + Pixelbreiten der zwischenliegenden Button)
Ist zwar nicht so schön wie ein ControlClick, aber in der Not... 
Ich persönlich bin der Meinung, dass man langsam, aber sicher, sich von BS kleiner Vista verabschieden sollte! Ansonsten hier eine Ausnahme, dort eine Ausnahme.
Ist aber nicht sehr logisch, da der Support für Vista noch vor dem für XP ausläuft. ( Wie das halt mit tot geborenen Kindern so ist. 
)
Ein Array muß bei der Deklaration mindestens ein Element beinhalten.
[autoit]Local $array['Anzahl_Elemente']
[/autoit]
