Je tu první verze Poznámkového bloku.
Je tu zatím úplně primitivní verze.
Děkuji za Komentáře ohledně bugů errorů a nedostatků nebo co bys te
chtěli mít v další verzi;).
Jako práce nic moc. Objektový návrh žádný. Využíváš akorát již
předepsané metody ovládacích prvků a pár dialogů. Vlastně jsi si akorát
vyhrál s designerem. Přijde mi to skoro jako z nějakého tutoriálu. Navíc i
obyčejný pozn. blok má více možností.
Jinak nic převratného to neni, na klávesovou skratku se u
ToolStripMenuItem používa vlastnost Shortcut, nic zvláštního na ni není,
takže sem ani nebudu dávat odkaz.
Nejsem moc dobry na programovany programuju trochu no tak tyden vic ne.
Z tutorialu to neni udelane a jěště jednou Nejsem Dobry Programator
Ale snazím se co to jde.
Proč jsi to sem dával? Proč nepočkáš, až se něco naučíš? Takhle
jen snížíš očekávání na minimum... Co je vlastně poznámkový blok -
textová plocha a pár metod - to prostě nemá smysl vydávat jako kdo ví
co...
Ale jen tak dál Zkus
ale spíše psát své vlsatní algoritmy To tě naučí mnohem více.
Ikdyž samozřejmě chápu, že poznáváš C# jako takový. Doporučuji si
projít tutoriály o OOP zde a to dříve, než se pustíš do okeních
aplikací. Ať víš, jak to funguje.
Doporučím ti jedno, zůstaň v konzoli. Strašně moc lidí se hrne do
Formů a přitom nezná ani metody.
Naprogramuj různé algoritmy (sám !), ať už třídící, různé
vyhledáváací apod. Zkus udělat piškvorky, lodě. Robota Karla co chodí a
plní tovje příkazy apod. A to vše v konzoli. I OOP se dá pěkne nacvčit se
vším možným v konzoli. Až budeš mít uděláno dost, jdi na Formy.
My jsme ve škole soobně ztrávili v konzoli přes půl roku. Až po
základu OOP jsme se vrhli na Formy.
Ale no tak - jazyk? To už jsi ty 2 roky měl věnovat C... Batch je jen
jakýsi Framework DOSu - je to jazyk, který umožňuje používat features
kernelu DOSu... Něco podobného je base (zkratka bas) mnohých DOSů...
Hlavní věc je to - co jsem psal... Při psaní DOSu vznikly funkce - TTY
výpis, zápis do souborového systému, beep, atd. No a Batch/BAS jen spravují
tyto funkce kernelu DOSu. Na Windows od 3.11 verze to pochopitelně fungovat
nemůže - když již není přístup k DOSovému kernelu - ne přímý... A to
co Windows 3.11+ poskytuje je, řekl bych, jen kvůli těm, co si Batch
oblíbili... Ale ztratit v tom 2 roky života? To je jako vyříznout si ledvinu
a udupat ji...
Na programátorskou ne, jinak zdravotní. (Zubní technik.)
Sorry, ale jak jsem psal - začínal jsem a neznal ničeho. Píšeš, že jsi
znal Javu a nevěděl jak ji nainstalovat. Já nevědel ani o Javě - co to
vůbec je. Přesto jsem si našel návody a vytvořil v ní pár programů. A
prostě bez šajna jak. Nejde mi o to ukázat na sebe jako na boha - omlouvám
se, ale neznám příběhy jiných. Žil jsem ve snech a nevěřil v naplnění.
Ale nikdy nenastavuji překážky - přehlížím je... Prostě Google tu je jak
dlouho a zadat tam "Jak začít programovat", atp. není zase tak
složité...
Když někdo zabalí celý adresář s projektem, do RARu a ještě to hodí
na uloz.to, ze kterého to mám občas problém stáhnout i rozbalit (ne vždy
sedím u PC), tak to svědčí o tom, že dotyčný toho ještě mnoho neví o
tom, co je to textový editor a co je to text. Docela mi vadí, že z takového
adresáře musím vyzobávat 2-3 soubory, které nesou užitečné informace
(soubory .cs). Zbytek je jen nezajímavý balast, který ocení asi jen
uživatelé VS apod.
Vlastně jsem rád, že v C# nedělám, protože s takovým ohavným
systémem by se mi pracovat nechtělo.
Já na tom bohužel nejsem se svým GM nijak lépe. Tam se toho nabaluje
celkem slušná hromada a "prázdný" exe má 2MB. Škoda, že mě to
nenechá
při exportu do exe vyházet nepotřebné části. To je jedna z prvních
věcí,
které měli yoyogames udělat, když převzali Game Maker. No, lidi se asi
nikdy nepoučí z chyb.
Třída napsaná v Javě mívá kolem 1 KB, přeložená do class ještě o
něco méně. Zabalením do jaru se aplikace ještě zmenší. Jen to běhové
prostředí bývá trochu větší, ale nějak tam těch 6000 tříd (nebo tak
nějak) nacpat museli. Naštěstí se běhové prostředí přenášet nemusí,
to má v zájmu bezpečnosti každý nainstalováno u sebe přímo od
výrobce.
Přenášet soubory .exe mezi systémy je dost velké bezpečnostní riziko,
kterým např. .jar netrpí. Proto moc nechápu některé požadavky těch,
kteří vyžadují .exe.
Jar nejde udělat nebezpečný? To že běží na virtuálním stroji
není
snad zas tak velký rozdíl, když bude mít do reálného systému práva.
Podle mě záleží jen na právech, která jsou spuštěnému programu
přidělena
a na ostatních věcech by snad záležet nemělo.
Záleží na tom, jak jsou nastavena práva ve virtuálním stroji. Pokud je
požadavek aplikace v rozporu s tímto nastavením, akce se neprovede a je
vyvolána běhová výjimka.
Defaultně jsou ta práva virtuálního stroje k operačnímu systému dost
volná, ale šrouby se utáhnout dají a také se to ve firemním prostředí
dělá. Nastavuje se to právě na tom virtuálním stroji.
Práva jsou na to, co se exe snaží udělat. UAC funguje docela dobře, ve
většině firem a škol nejsou na uživatelských stanicích administrátorská
práva. Když si někdo stáhne crack a ten dialog odklepne, tak se nemůže
divit, že má viry.
Ono by to šlo, kdybys sem poslal jen soubory .cs. O posílání celého
projektu vůbec nestojím. Znamená to pro mne hromadu úkonů navíc, než se k
těm zdrojákům dohrabu. Zbývající soubory vyhazuji, protože pro mne
nemají význam, jsou tam z mého pohledu jen jako balast.
Když tady vystavíš jen ty .cs, tak si to může přečíst každý.
"Zbytek je jen nezajímavý balast, který ocení asi jen uživatelé VS
apod.
Vlastně jsem rád, že v C# nedělám, protože s takovým ohavným
systémem by se mi pracovat nechtělo."
Balast? Já jsem za ten balast rád, některé soubory ukládají nastavení
kompilace, takže má potom člověk jistotu, že uz všech vývojářů se to
kompiluje se stejným nastavením, pak tam jsou soubory s resource (třeba
ikonka apod.), manifest (práva - jestli to třeba musíš spouštět jako
admin), sln (solution), což zastřešuje projekt nebo i víc projektů, takže
je máš otevřený dohromady a můžeš třeba nastavit, v jakém pořadí se
mají kompilovat, když jsou na sobě nějak závislý. Ostatní "balast" má
také svůj význam a z nějakého důvodu tam je.
Nastavení kompilace mám v build.xml, projekt se každému vývojáři
zkompiluje stejně nezávisle na platformě. Manifest se mi generuje automaticky
a upravuji ho jen, pokud je to nutné, opět v build.xml. Ikonky a další
doplňky umístím dle firemních pravidel a informace o umístění uložím
opět do build.xml. Pořadí kompilace a závislosti řeší zmíněný
build.xml, balení obstará (kupodivu) build.xml. Testování komponent dělám
přímo v editoru, testy jsou součástí zdrojáků. Ostatní je balast.
Mě se manifest také generuje automaticky a upravuji ho jen, když je to
nutné
No, je to hezké, že máš všechno v jednom souboru, ale když někdo chce
něco z toho mít nastavené jinak, tak to dělá problémy při verzování,
ne?
Já jen z verzování na chvíli třeba vyjmu jeden soubor a neverzuje se mi jen
ta část, co chci mít nastavenou individuálně.
Však v aktuálním adresáři mám vždy jen svou verzi. Ostatní
nepotřebuji, ty má zase třeba někdo jiný. Proč bych měl mít u sebe
všechno?
Když potřebuji data z jiné větve, tak si ten adresář přepnu do jiné
větve nebo udělám merge, pokud je chci začlenit do své větve.
Ten build.xml se samozřejmě dá podle potřeby rozdělit na víc souborů,
ale to má smysl až u hodně velkých projektů. Nejčastěji se to dělá tak,
že v každém podadresáři je jeden a prochází se rekurzívně. Jsou
poměrně malé a docela dobře se udržují.
Kdyby to nemělo význam, tak by se tento systém nepoužíval tak
masově.
Ten balast tam nacpala jedna firma, na které je spousta závislých
vývojářů. Firma, která vyvinula build.xml netrvá na používání celého
vývojového prostředí a ani netrvá na používání build.xml. Každý
vývojář prostě používá jen tu část, která mu vyhovuje.
Na jednoduché záležitosti používám Makefile. Mám jeden centrální a s
tím si většinou vystačím. Teprve pokud projekt překročí určitou
složitost, plynule přecházím na build.xml.
Děláme co je v našich silách, aby byly zdejší diskuze co nejkvalitnější. Proto do nich také mohou přispívat pouze registrovaní členové. Pro zapojení do diskuze se přihlas. Pokud ještě nemáš účet, zaregistruj se, je to zdarma.