🚀 go-pugleaf

Remek pisze:
> Witam
> 
> Mam program formatujący tekst i plik tekstowy. Przeciągam ikonę pliku
> *.txt na ikonę programu. Powoduje to uruchomienie programu. Co zrobić,
> aby w kontrolce Edit programu pojawiła się nazwa przeciągniętego pliku
> *.txt?

 Przy takim uruchomieniu nazwa pliku jest przekazywana za pomocą linii
poleceń. Odpowiednia funkcja API nazywa się GetCommandLine:

LPTSTR GetCommandLine(VOID)

 Zwraca ona wskaźnik do (adres) łańcucha znaków stanowiącego linię
poleceń bieżącego programu. Parametry (ale nie w Unikodzie i bez nazwy
programu) są też dostępne dla funkcji WinMain():

int WINAPI WinMain(

HINSTANCE hInstance, //
HINSTANCE hPrevInstance, //
LPSTR lpCmdLine, // wskaźnik do zakończonego bajtem zerowym łańcucha
		 // znaków stanowiącego linię poleceń
int nCmdShow //

);

 Źródło: plik HLP Win32 API.

-- 
Pozdrawiam/Regards - Bogdan                     (GNU/Linux & FreeDOS)
Kurs asemblera x86 (DOS, GNU/Linux):http://rudy.mif.pg.gda.pl/~bogdro
Grupy dyskusyjne o asm:  pl.comp.lang.asm alt.pl.asm alt.pl.asm.win32
www.JabberPL.org www.torproject.org Soft (EN): miniurl.pl/bogdro-soft

Bogdan (bogdro) pisze:
> Remek pisze:
>> Witam
>>
>> Mam program formatujący tekst i plik tekstowy. Przeciągam ikonę pliku
>> *.txt na ikonę programu. Powoduje to uruchomienie programu. Co zrobić,
>> aby w kontrolce Edit programu pojawiła się nazwa przeciągniętego pliku
>> *.txt?
> 
>  Przy takim uruchomieniu nazwa pliku jest przekazywana za pomocą linii
> poleceń. Odpowiednia funkcja API nazywa się GetCommandLine:
> 
> LPTSTR GetCommandLine(VOID)
> 
>  Zwraca ona wskaźnik do (adres) łańcucha znaków stanowiącego linię
> poleceń bieżącego programu. 

Łańcuch ów należy samodzielnie przeparsować w celu podzielenia go na 
kolejne parametry wywołania programu. W większości przypadków łańcuch 
będzie zawierał nazwę uruchamianego programu, jednakże może też jej nie 
zawierać - w takim przypadku następuje "zagubienie" pierwszego parametru 
wywołania, bo zwykle parser przyjmuje, że pierwszy parametr to nazwa exeka.

To tak gwoli uzupełnienia.

Pozdrawiam,
Morris

Użytkownik "Paweł Pawlak" napisał:

> > Bogdan (bogdro) pisze:

> > LPTSTR GetCommandLine(VOID)

> > Zwraca ona wskaźnik do (adres) łańcucha znaków stanowiącego linię
> > poleceń bieżącego programu.

> Łańcuch ów należy samodzielnie przeparsować w celu podzielenia go na
> kolejne parametry wywołania programu. W większości przypadków łańcuch
> będzie zawierał nazwę uruchamianego programu, jednakże może też jej nie
> zawierać - w takim przypadku następuje "zagubienie" pierwszego
> parametru wywołania, bo zwykle parser przyjmuje, że pierwszy parametr
> to nazwa exeka.

Po najechaniu ikoną pliku "content9.htm" na ikonę programu "Format.exe"
otrzymuję:

"E:\ArchRW4\Asembler\Asembler32\Masm32\CwiczMasm\Probny\FileName\
Format.exe"E:\ARCHRW4\ASEMBLER\ASEMBL~2\MASM32\CWICZM~1\PROBNY\FILENAME\
CONTENT9.HTM

Czyli funkcja podała nazwę pliku dużymi literami. Wyizolowuję z tego
"CONTENT9.HTM" i zamieniam na "content9.htm". Akurat w tym konkretnym
przypadku tak można, ale co będzie jak nazwa będzie taka:

"Content9.htm"

To na razie jednak zostawiam na później. Problem jest inny. Mimo podania
do bufora "nazwa_pliku" prawidłowej nazwy, funkcja CreateFileA zwraca
błąd tzn. nie znajduje pliku o podanej nazwie. Wywołanie jest
następujące:

invoke CreateFileA, addr nazwa_pliku, GENERIC_READ or GENERIC_WRITE,\
       0, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0

w eax zwracany jest wynik 0xFFFFFFFF, czyli błąd.

Jeśli na próbę usunę wywołanie GetCommandLine i podam nazwę do Edita
ręcznie, wszystko działa dobrze. Z Edita nazwę pobieram funkcją:

invoke GetWindowTextA, hEdit1, addr nazwa_pliku, 32

O co może chodzić? Jeśli nie podałem wszystkich potrzebnych danych,
proszę o pytanie dodatkowe.

Remek pisze:
> 
> Po najechaniu ikoną pliku "content9.htm" na ikonę programu "Format.exe"
> otrzymuję:
> 
> "E:\ArchRW4\Asembler\Asembler32\Masm32\CwiczMasm\Probny\FileName\
> Format.exe"E:\ARCHRW4\ASEMBLER\ASEMBL~2\MASM32\CWICZM~1\PROBNY\FILENAME\
> CONTENT9.HTM
> 
> Czyli funkcja podała nazwę pliku dużymi literami. Wyizolowuję z tego
> "CONTENT9.HTM" i zamieniam na "content9.htm". Akurat w tym konkretnym
> przypadku tak można, ale co będzie jak nazwa będzie taka:
> 
> "Content9.htm"

Nic nie będzie. Znaczy, nic złego się nie stanie. To nie "funkcja 
podaje" nazwę pliku wielkimi literami, ale powłoka (Explorer) ją taką 
przekazuje programowi. Skoro powłoka przekazuje nazwę pliku wielkimi 
literami, a na dysku jest zapisana małymi to oznacza, że wielkość liter 
nie ma znaczenia.

> To na razie jednak zostawiam na później. Problem jest inny. Mimo podania
> do bufora "nazwa_pliku" prawidłowej nazwy, funkcja CreateFileA zwraca
> błąd tzn. nie znajduje pliku o podanej nazwie. Wywołanie jest
> następujące:
> 
> invoke CreateFileA, addr nazwa_pliku, GENERIC_READ or GENERIC_WRITE,\
>        0, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0
> 
> w eax zwracany jest wynik 0xFFFFFFFF, czyli błąd.
> 
> O co może chodzić? Jeśli nie podałem wszystkich potrzebnych danych,
> proszę o pytanie dodatkowe.
> 

Co to jest nazwa_pliku i jaką ma zawartość?

Pozdrawiam,
Morris

Użytkownik "Paweł Pawlak" napisał:

> Nic nie będzie. Znaczy, nic złego się nie stanie. To nie "funkcja
> podaje" nazwę pliku wielkimi literami, ale powłoka (Explorer) ją taką
> przekazuje programowi. Skoro powłoka przekazuje nazwę pliku wielkimi
> literami, a na dysku jest zapisana małymi to oznacza, że wielkość liter
> nie ma znaczenia.

Faktycznie. Tego nie wiedziałem. Nie ma znaczenia jakiej wielkości liter
użyję w Edit. Plik jest prawidłowo znajdowany.

> Co to jest nazwa_pliku i jaką ma zawartość?

Bufor pamięciowy, do którego wczytywana jest nazwa z Edita funkcją
GetWindowText.

nazwa_pliku  db 32 dup(0)

Remek

Remek pisze:
> Użytkownik "Paweł Pawlak" napisał:
> 
>> Nic nie będzie. Znaczy, nic złego się nie stanie. To nie "funkcja
>> podaje" nazwę pliku wielkimi literami, ale powłoka (Explorer) ją taką
>> przekazuje programowi. Skoro powłoka przekazuje nazwę pliku wielkimi
>> literami, a na dysku jest zapisana małymi to oznacza, że wielkość liter
>> nie ma znaczenia.
> 
> Faktycznie. Tego nie wiedziałem. Nie ma znaczenia jakiej wielkości liter
> użyję w Edit. Plik jest prawidłowo znajdowany.
> 
>> Co to jest nazwa_pliku i jaką ma zawartość?
> 
> Bufor pamięciowy, do którego wczytywana jest nazwa z Edita funkcją
> GetWindowText.
> 
> nazwa_pliku  db 32 dup(0)

Mnie się raczej rozchodziło o to, co w danym momencie (przed wywołaniem 
CreateFile) znajduje się w tej zmiennej.

<quote>
Mimo podania do bufora "nazwa_pliku" prawidłowej nazwy, funkcja 
CreateFileA zwraca błąd tzn. nie znajduje pliku o podanej nazwie. 
Wywołanie jest następujące:

invoke CreateFileA, addr nazwa_pliku, GENERIC_READ or GENERIC_WRITE,\
        0, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0

w eax zwracany jest wynik 0xFFFFFFFF, czyli błąd.
</quote>

Uściślając, ważne jest, co tam się znajduje tuż przed wywołaniem 
funkcji. I nie, nie chodzi mi o to, co Ci się wydaje że tam jest lub co 
ma tam być ("No, jest tam nazwa pliku do otwarcia"), tylko co (jakie 
bajty) rzeczywiście się tam znajduje. I ewentualnie jak to tam 
umieszczasz, że CreateFile nie znajduje tego pliku.

Pozdrawiam,
Morris

Remek wrote:
> Po najechaniu ikoną pliku "content9.htm" na ikonę programu "Format.exe"
> otrzymuję:
> 
> "E:\ArchRW4\Asembler\Asembler32\Masm32\CwiczMasm\Probny\FileName\
> Format.exe"E:\ARCHRW4\ASEMBLER\ASEMBL~2\MASM32\CWICZM~1\PROBNY\FILENAME\
> CONTENT9.HTM
> 
> Czyli funkcja podała nazwę pliku dużymi literami. Wyizolowuję z tego
> "CONTENT9.HTM" i zamieniam na "content9.htm". Akurat w tym konkretnym
> przypadku tak można, ale co będzie jak nazwa będzie taka:
> 
> "Content9.htm"
> 
> To na razie jednak zostawiam na później. Problem jest inny. Mimo podania
> do bufora "nazwa_pliku" prawidłowej nazwy, funkcja CreateFileA zwraca
> błąd tzn. nie znajduje pliku o podanej nazwie. Wywołanie jest
> następujące:
> 
> invoke CreateFileA, addr nazwa_pliku, GENERIC_READ or GENERIC_WRITE,\
>        0, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0
> 
> w eax zwracany jest wynik 0xFFFFFFFF, czyli błąd.

A dlaczego niby system miałby otworzyć plik, do którego nie zna ścieżki 
(bo pracowicie ją wyrżnąłeś z łańcucha, który system przekazał do 
Twojego programu jako argument wywołania)?

Mam propozycję: zacznij programować w dowolnym języku wysokiego poziomu 
- C, C#, C++, czy jakimś Pascalopodobnym, zwalcz problemy, które nie 
mają nic wspólnego z językiem, a potem grzeb się w asemblerze. Tak 
będzie dużo łatwiej.

Użytkownik "Paweł Pawlak" napisał:

> > nazwa_pliku  db 32 dup(0)

> Mnie się raczej rozchodziło o to, co w danym momencie (przed wywołaniem
> CreateFile) znajduje się w tej zmiennej.

Bufor jest zainicjowany zerami.

1 wersja (pierwotna). W Edit wpisuję - "content9.htm". Po wykonaniu:

   invoke GetWindowTextA, hEdit1, addr nazwa_pliku, 32

w Buforze "nazwa_pliku" znajduje się "content9.htm" (w ASCII) i dalej
wszystko przebiega prawidłowo.

2 wersja (z GetCommandLine). Po:

 invoke GetCommandLine

pod adresem w eax znajduje się długi ciąg, który podałem wcześniej.
Wyłuskuję z niego:

CONTENT9.HTM

i wpisuję do zmiennej "nazwa_pliku".

Następnie wywołuję:

 invoke CreateFileA, addr nazwa_pliku, GENERIC_READ or GENERIC_WRITE,\
        0, 0, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, 0

 w eax zwracany jest wynik 0xFFFFFFFF, czyli błąd.

W argumencie "addr nazwa_pliku" jest właściwy adres i pod nim jest nazwa
pliku. Jednak funkcja zwraca błąd.

Jeśli uruchomię program podwójnym kliknięciem i wpiszę nazwę pliku do
edita program działa prawidłowo. Natomiast jeśli uruchomię z CommandLine
i potem wpiszę nazwę pliku w Edit, program twierdzi, że nie znalazł
pliku. Najlepiej chyba będzie jak wrzucę źródło i *.exe na stronę. Będzie
łatwiej analizować. Pliki są tutaj:

http://remek62.republika.pl/Tymcz/Format.zip

Źródło jest okrojone do minimum, ze względu na to, że cały plik jest dość
duży i zabałaganiony. W razie konieczności (i zrobieniu porządków) wrzucę
całość.

Remek

Użytkownik "Bernard" napisał:

> A dlaczego niby system miałby otworzyć plik, do którego nie zna ścieżki
> (bo pracowicie ją wyrżnąłeś z łańcucha, który system przekazał do
> Twojego programu jako argument wywołania)?

Bo jest niepotrzebna. Funkcja potrzebuje nazwy pliku znajdującego się w
tym samym katalogu.

> Mam propozycję: zacznij programować w dowolnym języku wysokiego poziomu
> - C, C#, C++, czy jakimś Pascalopodobnym, zwalcz problemy, które nie
> mają nic wspólnego z językiem, a potem grzeb się w asemblerze. Tak
> będzie dużo łatwiej.

Swoje propozycje zachowaj dla siebie i zajmij się własnymi problemami.
Chcesz mi zarżnąć kolejny wątek?

Remek

On 28.12.2007, Remek <wiasmed@neostrada.pl> wrote:
> Użytkownik "Bernard" napisał:
>
>> A dlaczego niby system miałby otworzyć plik, do którego nie zna ścieżki
>> (bo pracowicie ją wyrżnąłeś z łańcucha, który system przekazał do
>> Twojego programu jako argument wywołania)?
>
> Bo jest niepotrzebna. Funkcja potrzebuje nazwy pliku znajdującego się w
> tym samym katalogu.

No i co z tego, że w tym samym katalogu co plik wykonywalny? Słyszałeś
o czymś takim jak katalog bieżący?

>> Mam propozycję: zacznij programować w dowolnym języku wysokiego poziomu
>> - C, C#, C++, czy jakimś Pascalopodobnym, zwalcz problemy, które nie
>> mają nic wspólnego z językiem, a potem grzeb się w asemblerze. Tak
>> będzie dużo łatwiej.
>
> Swoje propozycje zachowaj dla siebie i zajmij się własnymi problemami.
> Chcesz mi zarżnąć kolejny wątek?

Naprawdę najpierw doucz się programować w ogóle, a dopiero potem bierz
za assemblera. To nie jest jednostkowa opinia Bernarda.

-- 
Secunia non olet.
Stanislaw Klekot

Użytkownik "Stachu 'Dozzie' K." napisał:

> No i co z tego, że w tym samym katalogu co plik wykonywalny? Słyszałeś
> o czymś takim jak katalog bieżący?

Przy takim wywołaniu:

.data

nazwa_pliku  db 32 dup(0)

.code

  invoke GetWindowTextA, hEdit1, addr nazwa_pliku, 32

Po wpisaniu w Edit nazwy pliku, pojawia się ona w zmiennej "nazwa_pliku"
w postaci wpisanej w Edit (bez ścieżki) i wywołanie:

   invoke CreateFileA, addr nazwa_pliku, ...

kończy się sukcesem.

> Naprawdę najpierw doucz się programować w ogóle, a dopiero potem bierz
> za assemblera. To nie jest jednostkowa opinia Bernarda.

Gdzie napisałem, że umiem wszystko i nie muszę się douczać? Do czego
zmierzają te bezczelne świadczące o braku choćby minimum kultury bycia
uwagi?

Plonk

Remek

On 28.12.2007, Remek <wiasmed@neostrada.pl> wrote:
> Użytkownik "Stachu 'Dozzie' K." napisał:
>
>> No i co z tego, że w tym samym katalogu co plik wykonywalny? Słyszałeś
>> o czymś takim jak katalog bieżący?
>
> Przy takim wywołaniu:
>
> .data
>
> nazwa_pliku  db 32 dup(0)
>
> .code
>
>   invoke GetWindowTextA, hEdit1, addr nazwa_pliku, 32
>
> Po wpisaniu w Edit nazwy pliku, pojawia się ona w zmiennej "nazwa_pliku"
> w postaci wpisanej w Edit (bez ścieżki) i wywołanie:
>
>    invoke CreateFileA, addr nazwa_pliku, ...
>
> kończy się sukcesem.

A plik się gdzie zapisuje? I z jakim katalogiem roboczym uruchamiasz
program?

>> Naprawdę najpierw doucz się programować w ogóle, a dopiero potem bierz
>> za assemblera. To nie jest jednostkowa opinia Bernarda.
>
> Gdzie napisałem, że umiem wszystko i nie muszę się douczać? Do czego
> zmierzają te bezczelne świadczące o braku choćby minimum kultury bycia
> uwagi?

Te uwagi ani nie są bezczelne, ani nie świadczą o braku kultury. Mylisz
kulturę z bardzo kiepską opinią o twojej obecnej wiedzy i arogancji.

> Plonk

Nie mój problem. To nie ja będę pytać i oczekiwać odpowiedzi od ciebie.

-- 
Secunia non olet.
Stanislaw Klekot

Remek wrote:

>> No i co z tego, że w tym samym katalogu co plik wykonywalny? Słyszałeś
>> o czymś takim jak katalog bieżący?
> 
> Przy takim wywołaniu:
> 
> .data
> 
> nazwa_pliku  db 32 dup(0)
> 
> .code
> 
>   invoke GetWindowTextA, hEdit1, addr nazwa_pliku, 32
> 
> Po wpisaniu w Edit nazwy pliku, pojawia się ona w zmiennej "nazwa_pliku"
> w postaci wpisanej w Edit (bez ścieżki) i wywołanie:
> 
>    invoke CreateFileA, addr nazwa_pliku, ...
> 
> kończy się sukcesem.

No i nie zrozumiales co Stachu chcial Ci przekazac. Jesli uruchomisz
program "recznie" katalog biezacy bedzie ustawiony na katalog z twoim
programem. Wtedy wszystko dziala.

Jesli natomiast program uruchamia sie po "upuszczeniu" na niego pliku,
katalog biezacy jest najprawdopodobniej zupelnie inny. Dlatego pracochlonne
wyrzniecie pelnej sciezki jest zupelnie nie ma miejscu.

>> Naprawdę najpierw doucz się programować w ogóle, a dopiero potem bierz
>> za assemblera. To nie jest jednostkowa opinia Bernarda.
> 
> Gdzie napisałem, że umiem wszystko i nie muszę się douczać? Do czego 
> zmierzają te bezczelne świadczące o braku choćby minimum kultury bycia
> uwagi?

No i po co ta pyskowka? Stachu zadal pytanie: "Słyszałeś
o czymś takim jak katalog bieżący?" ktore ty kompletnie zignorowales. A
inaczej ustawiony katalog biezacy to na 99.999% przyczyna niepowodzen
opisanych przez ciebie w tym watku. A wystarczylo zapytac chociazby
google... 

PS. Zainteresuj sie funkcja GetCurrentDirectory.
http://msdn2.microsoft.com/en-us/library/aa364934.aspx

-- 
Michal Schulz

Remek wrote:
> Gdzie napisałem, że umiem wszystko i nie muszę się douczać? Do czego
> zmierzają te bezczelne świadczące o braku choćby minimum kultury bycia
> uwagi?

Gdyby ktoś chciał być wobec ciebie chamski, to by napisał wprost, żeś
dureń.  A jest zupełnie inaczej, bo zarówno Bernard jak i Staszek dają
ci dobre rady i wskazówki (tracąc przy okazji swój czas).  Naprawdę
doceń to, że ktoś chce ci pomóc, a nie obrażaj na cały świat;  masz
PMS-a, czy co?

w.

Remek pisze:
[...]
> 
> Jeśli uruchomię program podwójnym kliknięciem i wpiszę nazwę pliku do
> edita program działa prawidłowo. Natomiast jeśli uruchomię z CommandLine
> i potem wpiszę nazwę pliku w Edit, program twierdzi, że nie znalazł
> pliku. 

Tak jak koledzy wspominali: chcesz wczytać plik bez podania ścieżki. 
Wyświetl sobie nazwę bieżącego katalogu (GetCurrentDirectory) - 
zobaczysz wtedy, że jest inna, gdy uruchomisz program za pomocą 
podwójnego kliknięcia i inna, gdy uruchomisz program przez 
przeciągnięcie na jego ikonę innego pliku. Tak widocznie działa powłoka 
systemu, na to nie ma rady. Najpewniej nie bez powodu, gdy przeciągasz 
plik na ikonę programu, w linii polecenia dostajesz go wraz z pełną 
ścieżką. To tyle w kwestii nieznalezienia pliku.

Mam inne uwagi:

1. U mnie ten program nawet nie pokazał okna (po CreateWindowEx 
dostawałem błąd nr 2) - powodem okazała się być niewłaściwa wartość 
parametru dwExStyle - podałeś WS_OVERLAPPEDWINDOW, a tymczasem powinno 
być WS_EX_OVERLAPPEDWINDOW

2. Zauważyłem, że nie parsujesz linii poleceń na okoliczność oddzielenia 
poszczególnych parametrów, tylko z marszu szukasz backslasha. A co, gdy 
nie zostaną podane parametry uruchomieniowe? Szukając backslasha 
najpewniej znajdziesz go w ... nazwie exeka, który właśnie uruchamiasz - 
a i to będzie źle, bo za nazwą znajduje się jeszcze cudzysłów oraz 
spacja. A gdy program zostanie uruchomiony z konsoli, np. "format 
content9.htm", to nawet nie znajdziesz backslasha.

Jeśli nie chcesz sam pisać procedury parsującej, skorzystaj z gotowca - 
GetCL. Aby użyć tej funkcji dodaj masm32.inc/masm32.lib

3. Duże bufory na dane umieszczaj w sekcji .data? - systemowy loader i 
tak je wypełni zerami przy uruchamianiu exeka, a nie będą zajmować 
miejsca w pliku

4. Zauważyłem również, że brak Ci kontroli błędów. Jeśli CreateFile się 
nie powiedzie (zwróci INVALID_HANDLE_VALUE), to nie musi oznaczać, że 
tego pliku nie ma. Zauważ, że otwierasz go do zapisu i odczytu, na 
wyłączność (dwShareMode = 0). Jeśli taki plik będzie wcześniej otwarty 
(i trzymany) przez inną aplikację (np. Word, bo Notepad tylko wczytuje 
plik z dysku i nie trzyma go otwartego), to CreateFile też zwróci błąd. 
A jaki to błąd, to przekonasz się przy pomocy GetLastError (do tego 
FormatMessage i MessageBox - wyświetl go sobie)

Pozdrawiam,
Morris

> Jeśli uruchomię program podwójnym kliknięciem i wpiszę nazwę pliku do
> edita program działa prawidłowo. Natomiast jeśli uruchomię z
> CommandLine i potem wpiszę nazwę pliku w Edit, program twierdzi, że nie
> znalazł pliku.

Przyczyna jest prosta, wystarczyło tylko trochę pomyśleć. Otóż w trakcie
takiego uruchamiania programu, plik "content9.htm" jest wczytywany do
pamięci i dlatego CreateFile nie ma do niego dostępu. Z tego co
wyczytałem, trudno będzie uzyskać uchwyt w pamięci tak otwartego pliku.
Przyjdzie chyba zrezygnować z tego sposobu i znaleźć inny.

Remek

Użytkownik "Paweł Pawlak" napisał:

> Tak jak koledzy wspominali: chcesz wczytać plik bez podania ścieżki.
> Wyświetl sobie nazwę bieżącego katalogu (GetCurrentDirectory) -
> zobaczysz wtedy, że jest inna, gdy uruchomisz program za pomocą
> podwójnego kliknięcia i inna, gdy uruchomisz program przez
> przeciągnięcie na jego ikonę innego pliku. Tak widocznie działa powłoka
> systemu, na to nie ma rady. Najpewniej nie bez powodu, gdy przeciągasz
> plik na ikonę programu, w linii polecenia dostajesz go wraz z pełną
> ścieżką. To tyle w kwestii nieznalezienia pliku.

W kwestii nieznalezienia pliku juz się sprawa wyjaśniła. Podałem tylko
ten okrojony "kawałek", aby można było zobaczyć jak podaję do zmiennej
nazwę pliku. Za chwile wrzucę wersję wczytującą nazwę pliku podaną w Edit
i będziesz mógł porównać. Ścieżka nie jest szukana.

> 1. U mnie ten program nawet nie pokazał okna (po CreateWindowEx
> dostawałem błąd nr 2) - powodem okazała się być niewłaściwa wartość
> parametru dwExStyle - podałeś WS_OVERLAPPEDWINDOW, a tymczasem powinno
> być WS_EX_OVERLAPPEDWINDOW

U mnie jest dobrze - Win98 SE. Może masz XP?

> 2. Zauważyłem, że nie parsujesz linii poleceń na okoliczność
> oddzielenia poszczególnych parametrów, tylko z marszu szukasz
> backslasha. A co, gdy nie zostaną podane parametry uruchomieniowe?
> Szukając backslasha najpewniej znajdziesz go w ... nazwie exeka, który
> właśnie uruchamiasz - a i to będzie źle, bo za nazwą znajduje się
> jeszcze cudzysłów oraz spacja. A gdy program zostanie uruchomiony z
> konsoli, np. "format content9.htm", to nawet nie znajdziesz backslasha.

Zauważyłem te efekty. To jest do dopracowania oczywiście. Zastosowaną
procedurkę napisałem "na szybko".

> Jeśli nie chcesz sam pisać procedury parsującej, skorzystaj z gotowca -
> GetCL. Aby użyć tej funkcji dodaj masm32.inc/masm32.lib

OK. Sprawdzę to.

> 3. Duże bufory na dane umieszczaj w sekcji .data? - systemowy loader i
> tak je wypełni zerami przy uruchamianiu exeka, a nie będą zajmować
> miejsca w pliku

Jw.

> 4. Zauważyłem również, że brak Ci kontroli błędów. Jeśli CreateFile się
> nie powiedzie (zwróci INVALID_HANDLE_VALUE), to nie musi oznaczać, że
> tego pliku nie ma.

W pełnej wersji jest obsługa błędu.

> Zauważ, że otwierasz go do zapisu i odczytu, na wyłączność
> (dwShareMode = 0).

Też w pierwszej chwili usiłowałem iść tym tropem, ale zauważ że nie
dochodzi do otwarcia pliku przez CreateFile. On już jest wcześniej
otwarty, więc ten parametr nie ma znaczenia.


Remek

Plik bez CommandLine jest tutaj:

http://remek62.republika.pl/Tymcz/Format2.zip


Remek

Remek wrote:

>> Jeśli uruchomię program podwójnym kliknięciem i wpiszę nazwę pliku do
>> edita program działa prawidłowo. Natomiast jeśli uruchomię z
>> CommandLine i potem wpiszę nazwę pliku w Edit, program twierdzi, że nie
>> znalazł pliku.
> 
> Przyczyna jest prosta, wystarczyło tylko trochę pomyśleć. Otóż w trakcie
> takiego uruchamiania programu, plik "content9.htm" jest wczytywany do
> pamięci i dlatego CreateFile nie ma do niego dostępu. Z tego co
> wyczytałem, trudno będzie uzyskać uchwyt w pamięci tak otwartego pliku.
> Przyjdzie chyba zrezygnować z tego sposobu i znaleźć inny.

Remek, TY SIE DZIWISZ ZE LUDZIE SIE NA CIEBIE WKURZAJA???!!!

Przykro mi to mowic, ale jestes cholernym leniem. Napisalem Ci (nie tylko ja
zreszta), ze jak upuszczasz ikonke pliku na ikonce twojego programu, to na
99.999% katalog biezacy jest inny.

Co wiecej, napisalem Ci zebys sprawdzil to sam. Zebys wywolal sobie funkcje
GetCurrentDirectory i przekonal sie o tym na wlasne oczy. Ale nie. Ty takie
komentarze ignorujesz (bo nie podalismy Ci gotowca) i gadasz dalej swoje.
Rob tak dalej, a na tej grupie *NIKT* Ci wiecej nie pomoze.

Znudzony twoim narzekaniem napisalem sobie miniaturowy program (w Delphi co
prawda, ale dobrze odzwierciedla Twoj problem). Program wyswietla tylko dwa
stringi - jeden pobrany za pomoca GetCurrentDirectory, a drugi pobrany za
pomoca GetCommandLine. I wiesz co? Jak uruchomie program bezposrednio, to
otrzymuje na przyklad cos takiego:

CurrentDir: G:\Projekty\
CommandLine: "G:\Projekty\Project1.exe"

A jak upuszcze na ikonke programu plik "moj_plik.txt" znajdujacy sie
chociazby i w *TYM SAMYM KATALOGU*, otrzymuje cos takiego:

CurrentDir: C:\Documents and Settings\Michal
CommandLine: "G:\Projekty\Project1.exe" "G:\Projekty\moj_plik.txt"

Zauwaz prosze, ze w tym wypadku CurrentDir czyli katalog biezacy, jest
*INNY*. Jesli wiec w swoim programie pracowicie wycinasz cala sciezke do
pliku (bo uwazasz, ze jest Ci przeciez zupelnie niepotrzebna), to pliku
otworzyc nie mozesz, bo windows nie znajduje go w *KATALOGU BIEZACYM*.

Zrozumiales chociaz troche?

PS. Kiedys ludzie proszacy o pomoc oczekiwali tylko *nakierunkowania* na
problem, bo wlasnoreczne dochodzenie do prawdy bylo dla nich wyzwaniem.
Podanie im gotowca tylko by ich obrazilo. Ty natomiast wlasnie na gotowca
liczyc. Jakiekolwiek proby nakierowania Cie na rozwiazanie koncza sie
fiaskiem - ignorujesz to po prostu.

Tak, od tego momentu uwazam ze jestes smierdzacym leniem oczekujacym na
gotowce.

-- 
Michal Schulz

Remek pisze:
> Użytkownik "Paweł Pawlak" napisał:
> 
>> Tak jak koledzy wspominali: chcesz wczytać plik bez podania ścieżki.
>> Wyświetl sobie nazwę bieżącego katalogu (GetCurrentDirectory) -
>> zobaczysz wtedy, że jest inna, gdy uruchomisz program za pomocą
>> podwójnego kliknięcia i inna, gdy uruchomisz program przez
>> przeciągnięcie na jego ikonę innego pliku. Tak widocznie działa powłoka
>> systemu, na to nie ma rady. Najpewniej nie bez powodu, gdy przeciągasz
>> plik na ikonę programu, w linii polecenia dostajesz go wraz z pełną
>> ścieżką. To tyle w kwestii nieznalezienia pliku.
> 
> W kwestii nieznalezienia pliku juz się sprawa wyjaśniła. Podałem tylko
> ten okrojony "kawałek", aby można było zobaczyć jak podaję do zmiennej
> nazwę pliku. Za chwile wrzucę wersję wczytującą nazwę pliku podaną w Edit
> i będziesz mógł porównać. Ścieżka nie jest szukana.

No i znowu trzecia prawda. Jeśli uruchomisz program przez dwuklik i 
dopiero wpiszesz nazwę pliku do "sformatowania", to będzie dobrze. Jeśli 
przeciągniesz plik na ikonę programu i wtedy wpiszesz nazwę pliku, to 
będzie zonk. Najwyraźniej nie przeczytałeś, co do Ciebie wcześniej 
pisałem. Powtórzę więc:

JEŚLI URUCHAMIASZ PROGRAM PRZEZ DWUKLIKNIĘCIE JEGO IKONY TO BIEŻĄCY 
KATALOG BĘDZIE *INNY* NIŻ GDY URUCHOMISZ PROGRAM PRZEZ PRZECIĄGNIECIE I 
UPUSZCZENIE PLIKU NA JEGO IKONĘ.

I w tym leży Twój problem. Zróbże sobie prosty test:

   .386
   .model flat, stdcall
   option casemap:none

   include windows.inc
   include kernel32.inc
   include user32.inc
   includelib kernel32.lib
   includelib user32.lib

.data?
   buf db MAX_PATH dup (?)
.code
   caption db "Current directory:", 0

start:
   invoke GetCurrentDirectory, MAX_PATH, addr buf
   invoke MessageBox, NULL, addr buf, addr caption, MB_ICONINFORMATION
   invoke ExitProcess, 0
end start


I teraz odpal to raz przez dwuklik, a drugi raz przez przeciągnięcie 
jakiegokolwiek pliku na ikonę tego programu. Czy wyświetlona ścieżka 
będzie taka sama?

> 
>> 1. U mnie ten program nawet nie pokazał okna (po CreateWindowEx
>> dostawałem błąd nr 2) - powodem okazała się być niewłaściwa wartość
>> parametru dwExStyle - podałeś WS_OVERLAPPEDWINDOW, a tymczasem powinno
>> być WS_EX_OVERLAPPEDWINDOW
> 
> U mnie jest dobrze - Win98 SE. Może masz XP?

No i mimo zwróconej uwagi nie poprawiłeś tego. Nie bez powodu wartości 
mają _EX_ w nazwie, prawda? Są style zwykłe (WS_blabla) oraz style 
rozszerzone (WS_EX_blabla). Należy je używać w odpowiednich miejscach, a 
nie według swojego widzimisię.

Przy okazji - mam Win2k

> 
>> 4. Zauważyłem również, że brak Ci kontroli błędów. Jeśli CreateFile się
>> nie powiedzie (zwróci INVALID_HANDLE_VALUE), to nie musi oznaczać, że
>> tego pliku nie ma.
> 
> W pełnej wersji jest obsługa błędu.
> 
>> Zauważ, że otwierasz go do zapisu i odczytu, na wyłączność
>> (dwShareMode = 0).
> 
> Też w pierwszej chwili usiłowałem iść tym tropem, ale zauważ że nie
> dochodzi do otwarcia pliku przez CreateFile. On już jest wcześniej
> otwarty, więc ten parametr nie ma znaczenia.

Czytaj ze zrozumieniem. Parametr dwShareMode ma znaczenie, bo oznacza on 
(w wypadku wartości 0): "systemie, chcę otworzyć plik w taki sposób, aby 
nikt inny nie mógł z niego korzystać dopóki nie skończę pracy z tym 
plikiem". Jeśli ten twój plik będzie już wcześniej otwarty przez inną 
aplikację, która powiedziała "systemie, otwórz ten plik, ale żeby inni 
też mogli go otworzyć w tym samym czasie", to dostaniesz błąd pomimo że 
ten plik istnieje, bo system nie może spełnić Twojego żądania (zabronić 
innym otwarcia pliku).

Pozdrawiam,
Morris

Użytkownik "Paweł Pawlak" napisał:

> U mnie ten program nawet nie pokazał okna ...

Zmieniłem. Sprawdź, czy teraz działa.

Remek

Użytkownik "Michal Schulz" napisał:

Nieważne co napisał. Same bzdury. Zawsze się zastanawiałem obserwując
takie dyskusje skąd się biorą takie agresywne dupki? Zamiast siedzieć
spokojnie na dupie i nie wierzgać nogami jak ich nie p.... podskakują jak
wsza na grzebieniu i szukają okazji, aby za wszelką cenę komuś dopiec,
poniżyć go, ocenić wedle swojego marnego systemu wartości. Jeśli uznają
kogoś za mniej wiedzącego od siebie nie wahają przed okazaniem mu pogardy
i swojej niby wyższości. To są marni ludzie. Kto dał Ci baranie
jakiekolwiek prawo do oceniania kogokolwiek w taki sposób? Zajmuj się
swoimi sprawami, a ode mnie wara. G... mnie Twoje obchodzą opinie
(niezrównioważonego osobnika).

Remek

Remek wrote:

> Nieważne co napisał. Same bzdury.

Doprawdy?

> Zawsze się zastanawiałem obserwując 
> takie dyskusje skąd się biorą takie agresywne dupki?

Spojrz na ton swojej wypowiedzi i zastanow sie kto tutaj jest agresywny.

> podskakują jak
> wsza na grzebieniu i szukają okazji, aby za wszelką cenę komuś dopiec,
> poniżyć go, ocenić wedle swojego marnego systemu wartości. 

ludzie tutaj probuja ci podpowiedziec. A ty tupiesz nozkami jak male dziecko
bo nie dostales "gotowca" :)

> Kto dał Ci baranie
> jakiekolwiek prawo do oceniania kogokolwiek w taki sposób? Zajmuj się
> swoimi sprawami, a ode mnie wara. G... mnie Twoje obchodzą opinie
> (niezrównioważonego osobnika).

PLONK

Z Chamami nie rozmawiam. Pa!

-- 
Michal Schulz

Dnia Fri, 28 Dec 2007 12:11:19 +0100, jakże pięknego
Bernard <bernard@earth.net> wystukał co zawarte poniżej:

: Mam propozycję: zacznij programować w dowolnym języku wysokiego poziomu 
: - C, C#, C++, czy jakimś Pascalopodobnym,

...

Równie dobrze mogłeś napisać: 
''...wysokiego poziomu - Pascal, Object Pascal czy jakimś Cpodobnym''

Twoim zdaniem, OP jest jakiś inny? Gorszy? 

-- 
Home: admin.idns.pl
Linux registered user: 408584
Contact: GG#44450, solaris#idns.pl
19:16:28 -!- Platyna Erroneous Nickname 

Solaris pisze:
> Dnia Fri, 28 Dec 2007 12:11:19 +0100, jakże pięknego
> Bernard <bernard@earth.net> wystukał co zawarte poniżej:
> 
> : Mam propozycję: zacznij programować w dowolnym języku wysokiego poziomu 
> : - C, C#, C++, czy jakimś Pascalopodobnym,
> 
> ...
> 
> Równie dobrze mogłeś napisać: 
> ''...wysokiego poziomu - Pascal, Object Pascal czy jakimś Cpodobnym''
> 
> Twoim zdaniem, OP jest jakiś inny? Gorszy? 
> 
Koledzy... spuśćcie trochę pary... bo się święta wojna zaczyna.

Paweł P.: Z przykrością muszę stwierdzić, że Twoje stanowisko jest 
cokolwiek nieuzasadnione. Wiem, że się uczysz. Ale grupa jest po to by 
*wskazać* Tobie rozwiązanie a nie *rozwiązać za ciebie* problem. W 
dodatku nawet "dziękuję" nie zauważyłem, pomimo tego, że koledzy 
produkowali się jak mogli by wytłumaczyć Tobie o co chodzi.

A wulgaryzmy to sobie zostaw na inne okazje.
Swoją drogą, będziesz miał ciężką drogę do przejścia jeśli ta lekcja 
niczego Cię nie nauczyła. I na koniec lektura: http://rtfm.killfile.pl/


Pozdrawiam

K.