Seite 1 von 1
15 Dateien Bug
#1
geschrieben 17. Januar 2010 - 15:49
hallo, den einen oder anderen dürfte es aufgefallen sein,
dass W7 ein merkwürdigen bug bzw. ehr ein feature hat.
und zwar wenn man im dateiexplorer mehr als 15 dateien ausgewählt hat,
dann werden nicht mehr die deteils angezeigt
und man muss erstmal auf "Weitere Deteils anzeigen..." klicken
nunja die gängelung währ ja nicht so schlim, wenn nicht das zweite problem währe.
denn wenn man bei mehr als 15 ausgewählte dateien das kontecktmenü öffnet,
dann sinnd alle programmeinträge weg.
dass W7 ein merkwürdigen bug bzw. ehr ein feature hat.
und zwar wenn man im dateiexplorer mehr als 15 dateien ausgewählt hat,
dann werden nicht mehr die deteils angezeigt
und man muss erstmal auf "Weitere Deteils anzeigen..." klicken
nunja die gängelung währ ja nicht so schlim, wenn nicht das zweite problem währe.
denn wenn man bei mehr als 15 ausgewählte dateien das kontecktmenü öffnet,
dann sinnd alle programmeinträge weg.
Anzeige
#3
geschrieben 17. Januar 2010 - 18:23
na super...
ne lösung ist wohl nicht bekannt, oder?
ne lösung ist wohl nicht bekannt, oder?
#5
geschrieben 17. Januar 2010 - 20:39
Was meinst du mit "Alle Programmeinträge sind dann weg" ?
Es ist nicht alles Chrome was glänzt. Firefox -Der bessere Browser
#6
geschrieben 18. Januar 2010 - 09:48
#7
geschrieben 18. Januar 2010 - 11:05
ist kein bug, lässt sich auch ienstellen , bin leider gerade nicht zuhause aber kenne das problem und musste es über die registry teilweise ändern. werd das ganze hier posten , also hoffnung darfst du haben
#8
geschrieben 19. Januar 2010 - 01:46
#9
geschrieben 21. Januar 2010 - 15:27
habe eben herausgefunden , das Kontextmenüeinträge sich differenziert verhalten.
Der 15 dateien bug/feature tritt nur auf, wenn keine DLL dafür verantwortlich ist, sprich wenn keine dll geladen wird, sondern nur ein kleiner befehl zum öffnen eines externen programmes weitergeleitet wird.
Nun hab ich aber noch einen workaround.
du könntest hergehen und zunächst herausfinden, welcher befehl benutzt wird, um die mp3 dateien zu konvertieren.
dies findest du raus indem du die registry öffnest und einfach nach dem wortlaut suchst, der auch in dem kontext menü ist.
Dann wirst du den ordner erweitern , wo dann command zu finden ist, und dort einen regschlüssel finden der dir den pfad verrät mit der genauen anweisung.
diese kopierst du einfach.
als nächstes drückst du Windows+R und gibst dann "shell:sendto" ein.
es öffnet sich der Ordner, SendTo wo du verknüpfungen ablegen kannst. Hier erstellst du eine verknüpfung zu den programm , der diese anweisung beinhaltet. zu finden ist das ganze dann im kontextmenü unter "senden an"...
Vielleicht hilft dir das ja weiter. falls meine erklärung zu wirr sein sollte, kann ich gern nen videotut posten
..
mfg
Der 15 dateien bug/feature tritt nur auf, wenn keine DLL dafür verantwortlich ist, sprich wenn keine dll geladen wird, sondern nur ein kleiner befehl zum öffnen eines externen programmes weitergeleitet wird.
Nun hab ich aber noch einen workaround.
du könntest hergehen und zunächst herausfinden, welcher befehl benutzt wird, um die mp3 dateien zu konvertieren.
dies findest du raus indem du die registry öffnest und einfach nach dem wortlaut suchst, der auch in dem kontext menü ist.
Dann wirst du den ordner erweitern , wo dann command zu finden ist, und dort einen regschlüssel finden der dir den pfad verrät mit der genauen anweisung.
diese kopierst du einfach.
als nächstes drückst du Windows+R und gibst dann "shell:sendto" ein.
es öffnet sich der Ordner, SendTo wo du verknüpfungen ablegen kannst. Hier erstellst du eine verknüpfung zu den programm , der diese anweisung beinhaltet. zu finden ist das ganze dann im kontextmenü unter "senden an"...
Vielleicht hilft dir das ja weiter. falls meine erklärung zu wirr sein sollte, kann ich gern nen videotut posten
..
mfg
#10
geschrieben 21. Januar 2010 - 16:11
Dieser Bug ist gewollt und soll den User vor sich selber schützen.
Wenn man x-beliebig viele Dateien markieren und dann an ein Shell-Command sendet, würde die Shell das Zielprogramm auch x-Mal starten, was zu Problemen führen kann (Speicherauslastung, Bedienbarkeit, etc.).
Bei Shellerweiterungen ist es etwas anders, weil deren Aufrufe anders ablaufen. Da kann das nur passieren wenn der DLL-Entwickler es absichtlich provoziert.
Wenn man x-beliebig viele Dateien markieren und dann an ein Shell-Command sendet, würde die Shell das Zielprogramm auch x-Mal starten, was zu Problemen führen kann (Speicherauslastung, Bedienbarkeit, etc.).
Bei Shellerweiterungen ist es etwas anders, weil deren Aufrufe anders ablaufen. Da kann das nur passieren wenn der DLL-Entwickler es absichtlich provoziert.
#11
geschrieben 21. Januar 2010 - 17:02
Zitat (DennisMoore: 21.01.2010, 16:11)
Dieser Bug ist gewollt und soll den User vor sich selber schützen.
Wenn man x-beliebig viele Dateien markieren und dann an ein Shell-Command sendet, würde die Shell das Zielprogramm auch x-Mal starten, was zu Problemen führen kann (Speicherauslastung, Bedienbarkeit, etc.).
Bei Shellerweiterungen ist es etwas anders, weil deren Aufrufe anders ablaufen. Da kann das nur passieren wenn der DLL-Entwickler es absichtlich provoziert.
Wenn man x-beliebig viele Dateien markieren und dann an ein Shell-Command sendet, würde die Shell das Zielprogramm auch x-Mal starten, was zu Problemen führen kann (Speicherauslastung, Bedienbarkeit, etc.).
Bei Shellerweiterungen ist es etwas anders, weil deren Aufrufe anders ablaufen. Da kann das nur passieren wenn der DLL-Entwickler es absichtlich provoziert.
Bei heutiger Hardware sollte das kein Problem sein mal von Netbooks abgesehen .
#12
geschrieben 21. Januar 2010 - 18:53
ich weis das microsoft den benutzer vor sich selbst schützen will,
mich braucht man nicht schützen
ich weis genau was passiert wenn ich 20 dateien gleichzeitig ausführe...
der SendTo-Workaround kommt für mich nicht in frage,
da ich die funktionen auf die dateitypen beschränk lassen will,
sendto arbeitet global
edit: und mein 4-kerner würde sich mal feuen wenn er mal auf vollast laufen darf
mich braucht man nicht schützen
ich weis genau was passiert wenn ich 20 dateien gleichzeitig ausführe...
der SendTo-Workaround kommt für mich nicht in frage,
da ich die funktionen auf die dateitypen beschränk lassen will,
sendto arbeitet global
edit: und mein 4-kerner würde sich mal feuen wenn er mal auf vollast laufen darf
Dieser Beitrag wurde von Mik.c.OS bearbeitet: 21. Januar 2010 - 18:54
#13
geschrieben 22. Januar 2010 - 09:25
Zitat (Mik.c.OS: 21.01.2010, 19:53)
ich weis das microsoft den benutzer vor sich selbst schützen will,
mich braucht man nicht schützen
ich weis genau was passiert wenn ich 20 dateien gleichzeitig ausführe...
der SendTo-Workaround kommt für mich nicht in frage,
da ich die funktionen auf die dateitypen beschränk lassen will,
sendto arbeitet global
edit: und mein 4-kerner würde sich mal feuen wenn er mal auf vollast laufen darf
mich braucht man nicht schützen
ich weis genau was passiert wenn ich 20 dateien gleichzeitig ausführe...
der SendTo-Workaround kommt für mich nicht in frage,
da ich die funktionen auf die dateitypen beschränk lassen will,
sendto arbeitet global
edit: und mein 4-kerner würde sich mal feuen wenn er mal auf vollast laufen darf
Tja, aber da MS nicht für dich programmiert, sondern für Millionen von Usern müssen sie Kompromisse machen. Man weiß ja wie Leute reagieren wenn Windows mal abstürzt oder arg langsam wird.
Mußt du dir halt ne Shell-Extension schreiben.
@ReviRd-Revo:
Wenn du auf einem heutigen Rechner 20-30 Prozesse startest die jeweils 1 Datei öffnen, Daten lesen und in eine anderen Datei schreiben (Videokonverter z.B. oder Demuxer), dann ist das auch auf mordernen Rechnern ein Problem. Zumindest wenn man nur 1 Platte und kein RAID hat.
Thema verteilen:
Seite 1 von 1