🚀 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.