Witam,
troche się zawiesiłem na pozornie prostym problemie:
jak wczytać do komponentu RichEdit (a dokładnie dodać do wyświetlanej już zawartości (Lines->Add())
zawartość następującego pliku:
http://www.speedyshare.com/data/694154723/11522126/55218166/log.TXT
Dla leniwych:
plik zawiera takie badziewie:
´ şÍ!´ ͸ LÍ!Czesc.
Stosując normalne mechanizmy, wywala błąd.
Zadowalający byłby chociaż efekt podobny do wklejenia zawartości tego pliku z notatnika.
Jak rozwiązać ten problem ?
To nie jest plik tekstowy i nie wczytasz tego do komponentu
który pracuje z plikami .txt .doc czy .rtf.
Plik zawiera znaki które nie mieszczą sie w zakresie "reprezentowanym" przez RichEdit
event. trzeba przetworzyć plik i odrzucić "nieprzyswajalne" znaki
lub znając jego format odczytać dane które zawiera i przerobic je na tekst .
A właściwie po co go oglądać ...?
Nic tam nie ma ciekawego ,obejrzyj go w Hex edytorze 80% to same 0...
Dlaczego go oglądać ?
Ano dlatego, że pisząc nakładkę graficzną dla np. takiego kompilatora asemblera istnieje możliwość otrzymania podobnych wyników przy kodowaniu programów asm.
A wynik przekierowany jest do pliku tekstowego "plik.exe > log.txt" i wczytywany do RichEdita.
Wygląda na to, że trzeba będzie obcinać wszystkie zera poza ostatnim.
Jezu miłosierny, weź nie czytaj pliku binarnego na chama jako tekstu tylko dlatego, że rozszerzenie txt ma ;/
for(int i=0; i<size; i++) if(data[i]<32 || data[i]>128) data[i]='_';
i tak przetworzoną tablicę wstaw do memo - wszystkie binarne 'śmieci', a nie tylko zera wyeliminujesz, w Memo1 będzie bardzo dobrze widać w jakich miejscach leży 'czysty tekst' w ASCII.
dzejo napisał(a)
[...]
Nic tam nie ma ciekawego ,obejrzyj go w Hex edytorze 80% to same 0...
offtopując pewnie dlatego, że przyjmuje się stałe wielkości dla tekstu w pliku, przez co 80% jest tak naprawdę nieużywana, ja zawsze tworząc swój binarny format przed tekstem zapodaje jego długość, żeby nie marnować miejsca i to samo radzę...
Ranides napisał(a)
Jezu miłosierny, weź nie czytaj pliku binarnego na chama jako tekstu tylko dlatego, że rozszerzenie txt ma ;/
Tak prawdę mówiąc to ja tworzę ten plik jest dla mnie obojętne jakie ma rozszerzenie.
W każdym razie jest dla mnie ważna jego zawartość, bo zawiera coś, co mogę wyświetlić jako wynik wykonania programu (niekoniecznie dobrze napisanego - ale o to chodzi, żeby to zobaczyć).
Mimo wszystko, dziękuje za utwierdzenie w przekonaniu, że inaczej niż myślałem nie wczytam takiej kaszany.
whitejack napisał(a)
Dlaczego go oglądać ?
Ano dlatego, że pisząc nakładkę graficzną dla np. takiego kompilatora asemblera istnieje możliwość otrzymania podobnych wyników przy kodowaniu programów asm.
A wynik przekierowany jest do pliku tekstowego "plik.exe > log.txt" i wczytywany do RichEdita.Wygląda na to, że trzeba będzie obcinać wszystkie zera poza ostatnim.
nie moge sie oprzec ze robisz cos nietrywialnego ale zabierasz sie do tego od khem strony :) moze zacznij od zarania dziejow - co robisz, co przetwarzasz, na czym pracujesz, co chcesz uzyskac?
quetzalcoatl napisał(a)
whitejack napisał(a)
Dlaczego go oglądać ?
Ano dlatego, że pisząc nakładkę graficzną dla np. takiego kompilatora asemblera istnieje możliwość otrzymania podobnych wyników przy kodowaniu programów asm.
A wynik przekierowany jest do pliku tekstowego "plik.exe > log.txt" i wczytywany do RichEdita.Wygląda na to, że trzeba będzie obcinać wszystkie zera poza ostatnim.
nie moge sie oprzec ze robisz cos nietrywialnego ale zabierasz sie do tego od khem strony :) moze zacznij od zarania dziejow - co robisz, co przetwarzasz, na czym pracujesz, co chcesz uzyskac?
Jedynie co chciałem uzyskać w tym temacie to odpowiedź na pytanie zawarte w 1 poście.
A cytowany przez ciebie jest jedynie odpowiedzią na pytanie dzejo, skąd takie pliki sie biorą i po co mi je.
Tak na marginesie: wykorzystuje przekierowanie wyniku do pliku.txt, ponieważ nie widzę możliwości wykorzystania potoku do zczytywania wyniku aplikacji 16-bitowych (które w Win NT są obsługiwane przez proces ntvdm.exe - a do niego (chyba) nie ma dojścia)
ooo i wlasnie, jednak jest nietrywialnie :) nie probowalem, ale wydaje mi sie ze da rade - konsolowe 16bitki wchodza w interakcje z konsola wiec stdin/stdout gdzies schowane miec powinny... ntvdm udaje srodowisko 16bit, wiec moze trzeba zlapac jego stdin/stdout ? PID powinien byc znany wiec uchwyt procesu tez, calkiem mozliwe ze da sie z systemu wyciagnac stdhandles procesu o danym handle.. ja probowalbym ta droga. niestety calkiem prawdopodobne ze ntvdm bedzie sie rzadzil jakimis swoimi dziwnymi prawami:|