🚀 go-pugleaf

Piotr Ga³ka <piotr.galka@cutthismicromade.pl> wrote:

> Problem:
> W okienku: Project - Options... - Application jest kwadracik na obraz
> Icon: i klawisz [Load Icon...] i oba s± na szaro.

W ¿yciu tego nie u¿ywa³em (pisujê tylko na Linuksa i embedded), ale Google
twierdzi, ¿e tak siê mo¿e dziaæ, je¶li aplikacja jest konsolowa, a nie
okienkowa. Jest?

https://www.decompile.com/cpp/faq/console_icon.htm

--
Mówi ziêæ do te¶ciowej:
- Gdzie mama jedzie?
- Na cmentarz.
- A kto rower przyprowadzi ??!!

W dniu 2024-02-29 o 14:57, Arnold Ziffel pisze:
> Piotr Gałka <piotr.galka@cutthismicromade.pl> wrote:
>
>> Problem:
>> W okienku: Project - Options... - Application jest kwadracik na obraz
>> Icon: i klawisz [Load Icon...] i oba są na szaro.
>
> W życiu tego nie używałem (pisuję tylko na Linuksa i embedded), ale Google
> twierdzi, że tak się może dziać, jeśli aplikacja jest konsolowa, a nie
> okienkowa. Jest?

Musiałem poszukać co to jest aplikacja konsolowa. Wychodzi na to że to
wtedy gdy interface jest tekstowy (jak w DOS).

Nic z tych rzeczy. To jest normalna okienkowa.
Jedyne co według mnie ją różni od tych w których to Load Icon nie jest
greyed jest to, że tamte tworzyłem od zera w Builderze 2010 a tę
zacząłem w Builderze 5 i potem przeniosłem do Buildera 2010.

Z przeniesieniem miałem problemy bo niby wczytał plik projektu i zapisał
jako swój, ale plików, które poprzednio były w projekcie nie było.
Musiałem je wszystkie dodać na nowo.

A potem mi to jakby działało, ale nie do końca.
Się okazało, że w głównym pliku .cpp do którego nigdy nie zaglądam
(Builder sobie nim rządzi) są tworzone dwa obiekty mojego głównego okna
(czyli pewnie miał tworzenie, ale nie miał modułu, jak dodałem moduł to
dopisał drugie tworzenie).

Teraz pomyślałem, żeby porównać ten plik dla tych co nie ma problemu i
dla tej obecnej.

W tamtych jest więcej form itp więc jest trochę różnic, ale zwróciła
moją uwagę jedna linijka:

w tamtych:
WINAPI _tWinMain(HINSTANCE, HINSTANCE, LPTSTR, int)
a w tej:
WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)

Różnice to "_t" i brak "T" w LPSTR.

Jak poprawiłem na tak jak w tamtych to błąd linkera:
Brakuje zewnętrznego WinMain referenced from .....7.0\LIB\COW32.OBJ
Nic mi to nie mówi (jestem programistą na 1/24 etatu - 2 tygodnie w roku).

Musiałem cofnąć _t. LPTSTR mu nie robi.
Ale Load Icon nadal na szaro.

Zrobię kiedyś tę aplikację od zera w BCB2010, to może będzie jak tamte.

Doprowadziłem program do stanu zadowalającego (napisanie go miało mi
zająć 3 dni, a zajęło półtora tygodnia) i wróciłem do czegoś co
przerwałem na te parę dni, czego absolutnie mi się nie chce robić, ale
bezwzględnie muszę.
Próbuję przeczytać (ze zrozumieniem) EN 62368-1 i idzie mi jak krew z
nosa. Jak kiedyś na forum IEEE napisałem, że 2 razy czytałem 60950-1 i
nadal nic nie rozumiem to mi napisali "welcome in the club".
A w wolnych chwilach (soboty) powoli redaguję krytyczny tekst na temat
60839-11-5, który mam zamiar w ramach (zapewne bezskutecznego)
"naprawiania świata" wysłać do iec.ch (poruszyłem ten temat na dniach na
p.m.e w wątku "Zwolnienia nie tylko w IT....").
P.G.

 > Zrobię kiedyś tę aplikację od zera w BCB2010, to może będzie jak tamte.
To chyba dobry trop. Ja zaczynałem karierę od C++ Builder. Wypracowałem
sobie wtedy metodę podnoszenia proj. do nowej wer.:
1. Tworzyłem nowy proj. w C++ Buidler w nowej wer.
2. Dodawałem wszystkie inne pliki czyli cpp, h i okna.

Ogólnie to działało. Jednak miałem doświadczenie tylko z wer. 1-5. Potem
to już był Linuks i Qt.

W dniu 27.02.2024 o 14:26, Piotr Gałka pisze:
> Pod Borland C++ Builderem 2010 napisałem (dawno) kilka prostych
> programików i nigdy wcześniej się z tym problemem nie spotkałem.

Jest dobra zasada jaką sobie wypracowałem:
***** W prof. proj. nie można stosować generatorów kodu których nie
można kontrolować.
W szczególności nie można stosować formatek w XML konwertowanych do C++.
Dlatego wszystkie "wizardy" odpadają. Bo to utrata kontroli. Jak ktoś
jest mocny to sam sobie napisze generator. W dodatku generatory dostawcy
mają tą cechę, że nie działają z klasami twojej firmy. A to poważne
ograniczenie, bo łamie kol. zasadę:
***** Należy izolować proj. od świata zewnętrznego.
W kodowaniu oznacza to m.in. przezywanie używanych typów i klas w celu
ich szybkiej podmiany gdy zachodzi taka potrzeba.

W dniu 3.03.2024 o 09:20, Jacek Marcin Jaworski pisze:
> ***** Należy izolować proj. od świata zewnętrznego.
> W kodowaniu oznacza to m.in. przezywanie używanych typów i klas w celu
> ich szybkiej podmiany gdy zachodzi taka potrzeba.

Taka potrzeba zachodzi dosyć często i to na późnych etapach proj. i
sprowadza się do konieczności dodawania kol. zm. do kl.

On 03/03/2024 09:22, Jacek Marcin Jaworski wrote:
>> ***** Należy izolować proj. od świata zewnętrznego.

Co najczęsciej sprawdzi się w dłuższym rzucie do:

https://en.wikipedia.org/wiki/Reinventing_the_wheel

W dniu 3.03.2024 o 17:16, heby pisze:
> On 03/03/2024 09:22, Jacek Marcin Jaworski wrote:
>>> ***** Należy izolować proj. od świata zewnętrznego.
>
> Co najczęsciej sprawdzi się w dłuższym rzucie do:
>
> https://en.wikipedia.org/wiki/Reinventing_the_wheel

Po co tak gadać jak nie ma się doświadczenia? Każdy proj. należy
izolować od świata zewnętrznego i to na wiele sposobów i to z wielu
powodów (z czego główny jest taki, że wszyscy chcą go ubić).

On 03/03/2024 17:28, Jacek Marcin Jaworski wrote:
>> https://en.wikipedia.org/wiki/Reinventing_the_wheel
> Po co tak gadać jak nie ma się doświadczenia?

Ja tak gadam, bo *MAM* doświadczenie.

> Każdy proj. należy
> izolować od świata zewnętrznego i to na wiele sposobów i to z wielu
> powodów (z czego główny jest taki, że wszyscy chcą go ubić).

Interesujące, ale patologie nie są raczej dobrym pomysłem na
statystyczną analizę.

Reużywanie gotowych i stabilnych rozwiązań zewnątrznych na dłuższą metę
jest gwarantem sukcesu. Jesli te rozwiązania się dodatkowo opensource,
to w przypadku fuckupu/porzucenia, można to podnieć i pchnąc dalej.
Prawda jednak taka, że ani stl, ani boost, ani Qt ani kilka innych
biblitek nie zostały porzucone od dziesięcioleci. Było by skrajnie
głupie reimplementowanie wszystkiego w imie jakieś pustej ideologi izolacji.

W dniu 3.03.2024 o 18:36, heby pisze:
> Było by skrajnie głupie reimplementowanie wszystkiego w imie jakieś
> pustej ideologi izolacji.

Nie chodzi o "implementowanie wszystkiego w imię jakiejś pustej ideologi
izolacji" - chodzi o inteligentne zabezpieczenie przed koniecznością
rozszerzenia danego typu.
W przypadku typów prostych w proj. przezywa się je w celu uniknięcia
różnic implementacyjnych w różnych kompilatorach. W każdym poważnym
proj. widzę takie podejście.
W przypadku kl. dostarczanych przez dostawców zewnętrznych konieczne
jest przezywanie ich #define lub usning po to by w razie potrzeby je
rozszerzyć bez przewalania całego kodu.
To podstawowa higiena pracy programisty C i C++. No ale widać ciągle są
braki w higienie.

On 03/03/2024 20:20, Jacek Marcin Jaworski wrote:
> Nie chodzi o "implementowanie wszystkiego w imię jakiejś pustej ideologi
> izolacji" - chodzi o inteligentne zabezpieczenie przed koniecznością
> rozszerzenia danego typu.

A z czego wynika potrzeba rozszerzenia?

> W przypadku typów prostych w proj. przezywa się je w celu uniknięcia
> różnic implementacyjnych w różnych kompilatorach. W każdym poważnym
> proj. widzę takie podejście.

Ja nie. Może to dlatego, że nikt przy zdrowych zmysłach nie ma *dwóch*
różnych kompilatorów pracujących w tej samej domenie ABI/typów.

> W przypadku kl. dostarczanych przez dostawców zewnętrznych konieczne
> jest przezywanie ich #define lub usning po to by w razie potrzeby je
> rozszerzyć bez przewalania całego kodu.

Więc nie korzystaj z binarek dostarczancyh przez zewnątrznych dostawców.

Zaś w przypadku, gdy nie masz wyjścia, zastosuj dobrze znaną metodę:
uszczelnianie szamba. Owrapuj to guano C jakimiś klasami i zapomnij. W
razie gdy dostawca wpadnie na pomysł zmiany: zmienisz sobie
wrappery/adaptery.

Ale zasada nr.1: nie stosować vendor-lockin, nawet kosztem spowolnienia dev.

> To podstawowa higiena pracy programisty C i C++. No ale widać ciągle są
> braki w higienie.

Podstawą pracy programisty C/C++ jest wspólne ABI. Jeśli nie masz
wspólnego ABI/typów to musisz mieć naprawdę bardzo dobry powód robienia
takiego szamba.

W dniu 2024-03-01 o 23:06, Jacek Marcin Jaworski pisze:
>  > Zrobię kiedyś tę aplikację od zera w BCB2010, to może będzie jak tamte.
> To chyba dobry trop. Ja zaczynałem karierę od C++ Builder. Wypracowałem
> sobie wtedy metodę podnoszenia proj. do nowej wer.:
> 1. Tworzyłem nowy proj. w C++ Buidler w nowej wer.
> 2. Dodawałem wszystkie inne pliki czyli cpp, h i okna.

Nie zajmuję się tym obecnie, kiedyś do tego wrócę.
Nie mam żadnego problemu z dodaniem cpp, czy h.
Ale okienek zrobionych pod starszym Builderem nigdy nie próbowałem jakoś
ręcznie dodawać do nowego programu (nie wiem czy nowa wersja łyknie
pliki zawierające definicję ekranu).
Akurat ekran jest do zrobienia od nowa żmudny - około 250 kontrolek w
oknie. Chcę je mieć ponazywane w systematyczny sposób, a nie znalazłem w
Builderze mechanizmu typu zaznaczam ileś jednakowych kontrolek i podaję
wspólny człon nazwy i żeby sam mi je ponazywał wstawiając na 2 ostatnich
znakach nazwy kolejny numer.
Robienie tego od nowa tylko po to aby coś co jest szare przestało być
szare średnio mi się uśmiecha :)
P.G.

heby <heby@poczta.onet.pl> wrote:

> On 03/03/2024 17:28, Jacek Marcin Jaworski wrote:
>
>> (z czego g³ówny jest taki, ¿e wszyscy chc± go ubiæ).

Dlaczego mieliby chcieæ go ubiæ?

> By³o by skrajnie g³upie reimplementowanie wszystkiego w imie jakie¶
> pustej ideologi izolacji.

Zna³em cz³owieka, który nawet w³asnego stringa implementowa³, bo nie ufa³
STL-owemu ("bo ja nie wiem, jak on tam w ¶rodku dzia³a"). Fachowiec, eh.

--
Mówi ziêæ do te¶ciowej:
- Gdzie mama jedzie?
- Na cmentarz.
- A kto rower przyprowadzi ??!!

W dniu 7.03.2024 o 03:28, Arnold Ziffel pisze:
> heby<heby@poczta.onet.pl>  wrote:
>
>> On 03/03/2024 17:28, Jacek Marcin Jaworski wrote:
>>
>>> (z czego główny jest taki, że wszyscy chcą go ubić).
> Dlaczego mieliby chcieć go ubić?

Z tego samego powodu dlaczego wielcy odkrywcy i wielcy geniusze umierają
młodo.

On 07/03/2024 03:28, Arnold Ziffel wrote:
> Znałem człowieka, który nawet własnego stringa implementował

Jes masa korporacji wymyślających takie kwadratowe rzeczy bezustannie, w
zasadzie cała poważna informatyka siedzi na wystruganych z patyków i
g... kwadratowych kołach. Niezliczona ilośc programistów jest tak
naprawdę konserwatywna i siedzi po uszy w C: "jak czegoś nie widze to
nie wiem jak działa", reimplementując wszystko ręcznie, wliczając
emulacje klas na makrach i odkrywając wzorce projektowe z czasów
asemblera. W zasadzie każdy zespół w dużym korpo, piszący coś od lat 30,
będzie miał takie "stringi" jako jedyne słuszne i doskonale sprawdzone
rozwiązanie które gwarantuje im dozywotnie zatrudnienie. To ideologia,
ale sprytna, pozwala doczekać na emeryturze, zanim przejmie ten biznes
AI i zaora.

Jacek Marcin Jaworski <jaworski1978@adres.pl> wrote:

>>>> (z czego g³ówny jest taki, ¿e wszyscy chc± go ubiæ).
>> Dlaczego mieliby chcieæ go ubiæ?
>
> Z tego samego powodu dlaczego wielcy odkrywcy i wielcy geniusze umieraj±
> m³odo.

A jaki to powód?

--
Pracownicy fabryki klejów, farb i lakierów wracali do domu przez
gadaj±cy las.