MFC editor
2021-03-19T21:04:33+01:00
2021-03-21T16:31:57+01:00
2022-07-20T11:11:54+02:00
  • Az MFC-vel alapvetően az a probléma, hogy egy régi technológia. Még a 90-es évek elején indult, és gyakorlatilag az volt a célja, hogy a natív Win32 helyett adjon a fejlesztők kezébe egy rendes objektum orientált szerkezetet, amelynek a segítségével komponens alapon lehetett Windows alá natív grafikus felület építeni. (Magára a Win32-re épült, igazából csak egy újabb réteg lett, amelynek a fejlesztés megkönnyítése volt a célja, nem az UI fejlesztés koncepciójának a megváltoztatása.) Ez természetesen a maga idejében jó és szép volt de azóta sok minden történt az C++-al és a Windows-al fejlesztői szempontból, amely miatt az MFC  elavultá, nehézkessé, és - sok esetben - bonyolulttá vált. Ez mellett megjelentek az új platformok, és nyelvek, amelyek új megközelítésben, és új technológiákat vezettek be, többek között a felület fejlesztést is újradefiniálták. Ezek már koncepcionális változásokat hoztak be a felület fejlesztésbe. Például a WPF, amely C# alapokon nyújt gazdag, komponens alapú szolgáltatásokat. C++ platformon pedig a Qt lépett be, mint Windows (és más) grafikus felületeket kínáló fejlesztői megoldás. Ezeknek az elsajátítása természetesen idő, de mivel ezeknek az egyik fő célkitűzése a rapid fejlesztés támogatása, ezért a tanulási idő hamar megtérülhet.

    Nem, de ehhez volt könyvem, és szeretem ha gépi kódra fordul a program, és nem kell automatikus dinamikusmemória-felszabadítás. 

    Ezek az indokok nem helyénvalóak, és eléggé gyenge lábakon állnak.
    Mindegyik mai technológiához, platformhoz vannak szakkönyvek, leírások, tutorial-ok, demók, stb. Azt elismerem, hogy az angol nyelv ismerete nélkül ezeket nehéz megtanulni, de azt hiszem az angol ismerete legalább forrás szöveg megértése szintjén elengedhetetlen egy fejlesztő esetében.
    Azt megtudom érteni, hogy fontos lehet a közvetlen gépi kódra történő fordítás. Én tudom ezt értékelni, és valós indokokkal meg is tudnám magyarázni, ha nekem valóban erre lenne szükségem, de a te esetedben azt gondolom - a bőséges leírásodból következtetve - hogy ez inkább csak egy "elképzelés" a részedről. Esetleg valahol egyszer erről olvastál, és teljesen meggyőzött arról, hogy a tárgykódú platformoknak milyen rossz tulajdonságaik vannak. Nem értek ezzel egyet, megvan a létjogosultságuk, különben nem használnák őket nap, mint nap kint az iparban.
    Az automatikus memória felszabadítás a hibalehetőségek számát csökkenti, illetve azt segíti elő, hogy ne a fejlesztőnek kelljen erre figyelnie. Nem fekete mágia, a rapid fejlesztés egyik megvalósítása. Természetesen mint mindennek vannak itt is hátrányok, de ezek eltörpülnek amellett, amelyet a memória hibás (programozott) lefoglalásából / felszabadításából lehet kihozni.

    Miért lehet vele szívni, miért kevés eredménnyel, miért 5-ször akkora munka megtanulni mint a WinForms-ot vagy a WPF-et?

    Egyszerűen azért, mert ma már - viszonyítás alapként egy mai, modern technológiához képest - bonyolult, és nincsenek meg benne azok az alapvető támogatási formák, amelyek elengedhetetlenek egy gazdag UI környezet felépítéséhez. Ráadásul mindezt olyan formában, amely támogatná a fejlesztést: nincs grafikus UI editor (bár harmadik feles, nem túl jó azt hiszem van), sem pedig egymásra építhető komponensek. Minden olyan komponenst, amely bonyolultabb egy alap Win32-es komponensnél magadnak kell összeállítanod, a hátterét lefejlesztened, és azt beillesztened úgy a saját programodba, hogy az megvalósítja az elképzeléseidet. Ha neked a fejlesztési idő elhanyagolható, akkor ez működhet is, de általában nem az, így olyan megoldásokat kell alkalmazni - és az új megoldások már ilyenek - amelyek a fejlesztési időt lerövidítik. Ipari szinten ez szinte elsődleges szempont, hobby / tanulásnál bekalkulálható.

    A leírásod alapján, hogy pontosan mi is a célod az egésszel, az MFC biztos, hogy nem az ideális választás. Azt, amit leírtál a tervezett programodról, én azt gondolnám, hogy egy sima Qt-s (C++), vagy WPF-es (C#)-os Windows-os desktop alkalmazás lehetne. Nem kell nagy bravúr hozzá. Valami mai, modern UI fejlesztői megoldást ki kell választani, semmi fekete mágia nincs bennük, meg kell őket tanulni, aztán - mivel neked már van is rá projekt terved - a tanulást azonnal hasznos céllal fel tudod használni. Természetesen a fenti kettő mellett további lehetőségek is vannak, szinte végtelen ma már a desktop UI fejlesztés a tárháza. Nézzél szét, próbáld ki őket, olvass utánuk, és kezdj el velük foglalkozni, dolgozni. MFC-re új projetet indítani ma már nem igazán bölcs döntés. Inkább csak már meglévő kódbázisok karbantartása miatt lehet rá szükség.
    Egyébként zárszóként még csak annyit, hogy a Microsoft-nál már többször felröppent az a hír, hogy az MFC-t kivezeti a támogatott technológiák közül, az, hogy még ma is támogatott, és elérhető, talán csak valami mélyebb üzleti döntés, de hogy meddig lesz még aktív, nem lehet tudni.
    Sok sikert! :)
    Mutasd a teljes hozzászólást!
  • MFC-s résszel egyetértek, nem hiszem, hogy érdemes sok energiát ebbe ölnöd. Persze kérdés, hogy mivel szeretnél foglalkozni, mert sok MFC-s legacy kód van, amikhez kell majd szakember karbantartani X év múlva is.

    Ha nem kimondottan célod, hogy megtanuld az MFC-t, akkor ma már ennél sokkal jobb platformfüggetlen lehetőségeid vannak egy UI létrehozására.
    Személy szerint a Qt-t preferálom, de nincs sok tapasztalatom a többi elterjedt hasonló framework-el.
    List of platform-independent GUI libraries

    ---

    Elõször is, a C++ egy elég alacsony szintû nyelv

    Ezzel mondjuk vitatkoznék.

     eleve ezer lehetõsége van az embernek, hogy lábon lõje magát vele

    Rossz programot minden nyelven lehet írni. C++-nak legnagyobb hátránya a lapos tanulási görbe (főleg ha a nyelv adta összes aspektusra kíváncsi az ember)

    Ráadásul nincs mögötte egy egységes framework

    Nem feltétlenül érzem hátránynak ezt. Miért jó, hogy a 'nyelv része' egy-egy könyvtár, melynek implementációja önmagában óriási feladat, millióféleképpen / millióféle módra kihegyezhető könyvtárak?
    A nyelv szóljon a 'core' dolgokról, aki kiakar adni egy fordítót, annak ne az XML/ XYZ parse-oló  vizualizáló algoritmusokra menjenek az erőforrásai. Nem kell egy Microscoft-hoz hasonló óriás mögé, hogy fent lehessen tartani, karbantartani és fejleszteni a nyelvet!

    pl .NET 'egységes framework' alatt hogyan csinálsz QR dekomozíciót, vagy SupportVectorMachine tanítást, esetleg kamera kalibrációt, vagy QR kód olvasást egy kevésbé ismert formátumról?

    Valóban óriási probléma, hogy ezek nem a C#/.NET részei? Mindent magadnak kell implementálnod miatta?
    Dehogy.
    Mutasd a teljes hozzászólást!
  • A menük nem jelennek meg teljesen, rá kell kattintani az alján a nyílszerűségre. Sehol se találom hogy lehetne ezt a tömörítést kikapcsolni. Az erőforrás-szerkesztőben a menünél se találom, MainFrm.cpp-ben 2 helyen van CBRS_FLYBY, CBRS_DYNAMIC, mind a 4-et megpróbáltam 1-esével megjegyzésbe tenni, de úgymaradt.

    Nekem jó a C++. A datagrid gondolom valami olyasmi mint a fájl-listában a többféleképpen rendezhető táblázat.
    Mutasd a teljes hozzászólást!
    Csatolt állomány
  • Elõször is, a C++ egy elég alacsony szintû nyelv, eleve ezer lehetõsége van az embernek, hogy lábon lõje magát vele. Persze ha profi C++-os vagy, és a kisujjadban van az C++ minden csínja-bínja, a design patternek, az ismert módok ahogy sérüléknységet, memóriaszivárgást lehet vele okozni, stb. akkor ez nem gond, csak akkor jó eséllyel meg sem nyitod ezt a topicot. Ráadásul nincs mögötte egy egységes framework, így ha nem magad akarod megírni az egész világot, akkor nekiállhatsz vadászni, hogy akkor most mire milyen könyvtárakat használok, azok milyen további könyvtárakat használnak, stb. Vagy használhatsz Pl. Qt-t amiben elég sok minden benne van, de neki is megvannak az árnyoldalai.

    A másik dolog, hogy az MFC egy elég alacsony szintû dolog, lényegében egy OOP wrapper a win32/win64 API fölé. Ami azt jelenti, hogy gyakorlatilag mindent neked kell megcsinálni, nem lesz egy datagrid vagy bármi más ami komplexebb mint a jó öreg win32. Picit olyan ez, mint ha assemblyben állnál neki könyvelõ progit írni.
    Mutasd a teljes hozzászólást!
  • Ezt egy kicsit kifejtenéd bővebben hogy miért? Ugyanis a többit nem ismerem. Miért lehet vele szívni, miért kevés eredménnyel, miért 5-ször akkora munka megtanulni mint a WinForms-ot vagy a WPF-et? Köszi.
    Mutasd a teljes hozzászólást!
  • Az MFC-vel szerintem sokat lehet szívni, és kevés eredménnyel. Ha mindenáron C++-ozni akar valaki ilyesmit csinálni, azt manapság inkább Qt-nek hívják. De szerintem így is 5x akkora falat mint egy C#/Winforms vagy akár WPF elsajátítása.
    Mutasd a teljes hozzászólást!
  • Nem, de ehhez volt könyvem, és szeretem ha gépi kódra fordul a program, és nem kell automatikus dinamikusmemória-felszabadítás. Tudtommal a .Net nem ilyen, és a WPF .NET-es, a WinForms is. Egyébként is, csak angolul lett volna leírás hozzá, a referencia, ami rengeteg, nincs olyan könyvem ami összeszedi miket kell tudni az óriási referenciából.
    Mutasd a teljes hozzászólást!
  • Valami múzeumban dolgozol ?
    Mutasd a teljes hozzászólást!
  • Lehet hogy egyszerűbb lenne egy CEdit objektumot létrehozni, és annak metódusával beolvasni bele a vágólapról, majd kiolvasni belőle és beszúrni a memóriában tárolt szövegfájlba? Vágólapra tevéskor pedig CRichEditCtrl, mivel formázni is akarom automatikusan: dőlt, félkövér, mivel a program dokumentációja meg LibreOffice Writer-ben készül, és ahhoz pont jó lesz az automatikus formázás.

    Megnyitás/mentéshez a Windowsba telepített kódlapokat MFC-ből gondolom nem tudom elérni, csak ATL, OLE, COM, COM+, DCOM, vagy akármiből.
    Mutasd a teljes hozzászólást!
  • Már nem tudom szerkeszteni. Grafikus programnál is van amikor többsoros szöveget kell kiírni, akár több oldalasat. Jól látom, hogy ezt nekem kell megcsinálnom, mert nincs az MFC-ben? Tehát úgy mint parancssorosnál. Mondjuk egy szövegmezőt (CEditBox) ki lehet nagyítani hogy fedje el az egész ablakot, vagy CEditView, és abba lehet írni. Viszont ha én számokat is ki akarok írni: a szöveg végéhez kell hozzáfűzni ez esetben ugye, akkor azt már nekem kell megcsinálni? Egy olyan objektum kellene, mint a wcout, amibe lehet kiírni szöveget, számot, stb. Egyébként lehetséges parancssor-ablakot nyitni grafikus programból és oda írni? Vagy fordítva, parancssoros programból megjeleníteni mondjuk egy CFileDialog-ot, vagy egy CEditView-t? Nem arra gondoltam hogy egy exec funkció meghívásával elindítok egy másik programot. Azt tudom hogy lehet: parancssorban működik a notepad parancs, a Visual Studio el tudja indítani a parancssoros programjaimat. Igazából parancssoros ablakot nyitni és beleírni azért nem jó, mert a matematikai szimbólumok nem jelennek meg: rossz a Unicode-támogatása.

    A projekt létrehozásakor milyen stílust válasszak? MFC standard, Visual Studio, stb. És a többi beállítás mi legyen?
    Mutasd a teljes hozzászólást!
  • Visual C++ 2019-ben MFC-t használok, és egy csak szöveg formátumú szövegszerkesztőt szeretnék készíteni, amely megmutatja a zárójel párját: más a háttérszín nála. A sorköz is nagyobb lenne. Korábban szinte alig készítettem grafikus programot, csak parancssorosat. A korábbi grafikus programoknál csak megnéztem hogy ahhoz amit csinálni akarok mi kell, a többit nem tanultam meg. Most Sipos Marianna: "A Visual C++ és az MFC" könyvét tanulmányoztam át, megcsináltam a feladatokat, felírtam belőle egy fájlba amiket tudni kell: szerencsére letölthető pdf-ben a könyv, kijelöltem, beillesztettem LibreOffice Writer-be, kitöröltem belőle ami nem kell magyarázó szöveg mert már tudom, beleírtam aminek utánanéztem: CScrollView, stb. MDI-re gondoltam, ebben CScrollView-ra, viszont a görgetősávokon kívül ki szeretném írni a kurzor alatti karakter kódját és a kurzorpozíciót. Mivel 16:9 arányú monitorom van, majdnem negatív a magassága, és jó lenne ha minél több sor lenne látható, mivel ez egy IDE lesz a saját leírónyelvemhez, ezért nem lenne állapotsor, hanem a szöveg mellé írnám ki. Mondjuk bal oldalon lenne a menü, jobb oldalon a megnyitott fájlok nevei, középen a szöveg. Mint a Visual Studio IDE-ben a Solution Explorer meg a ToolBox. Ehhez gondolom szalagmenü kell, és nem szabad engedni hogy a szövegszerkesztő ablaka elfoglalja a teljes ablakot, mert a 2 szélén még vannak adatok. A kurzorpozíció+karakterkód kiírása mindegy hova kerülne, az egyik szélén lenne egy státuszsort helyettesítő valami. Úgy is lehet, hogy a kurzorpozíció a szövegszerkesztő ablak része, de a görgetősávon kívül kellene legyen. Ezt hogy lehet megcsinálni? A CScrollView-et el tudom helyezni egy CView közepén? Vagy legyen valami görgetősávos párbeszédablak számára kifejlesztett osztályban a szerkesztett szöveg, vagy hogy?

    Nem találtam speciális karakter beszúrására párbeszédablakot: olyat mint a Word-ben vagy LibreOffice Writer-ben van. Annál ki lehet választani a tartományokat is: görög betűk, matematikai szimbólumok, stb. Ha én csinálok egy sajátot, akkor ilyenek nem lennének, csak egy 16*4096-os táblázat, meg billentyűzetről beírható kód. Van ilyen készen? CCommonDialog leszármazottai között nincs.

    A CEditView szintaxiskiemeléshez kevés, így a vágólapot is nekem kell kezelnem. A vágólapról beolvasásra nem volt példa, a GetClipboardData egy HANDLE-t ad. Akkor azt a WinAPI GetFileSizeEx, ReadFile rutinjával kezeljem? Le kell zárni? Ha például Visual Studio-ból áthelyezek egy szöveget a vágólapra, és beillesztem LibreOffice Writer-be, akkor megmarad a szintaxiskiemelés, ha jegyzettömbbe illesztem be, akkor is működik. Nekem ugye csak szöveg kell. Mi történik, ha formázott szöveg van a vágólapon? Nekem kell kezelni ezt is, vagy ha Unicode szöveget kérek, átalakítja maga?

    A teljes képernyő működés hogy legyen? CMDIFrameWndExt-ben van EnableFullScreenMode, ShowFullScreen. De gondolom úgy is lehet hogy a CMainFrm-ben kikapcsolom a fejléc megjelenítését, a menüét nem kell mert az úgyis függőleges lesz. Hogy csináljam? És itt jön be, hogy a kurzor alatti karakter kódja, meg a kurzorpozíció a görgetősávon kívül van. Elvileg úgy is jó ha teljes képernyős módban nem látszik. Ha mondjuk egy monitortesztelő vagy videolejátszó programot írnék, akkor hogy kellene csinálni? Ennél is ott kell legyenek azok a vezérlők amik ablakban működéskor ott vannak, és ugye ha a teljes képernyőt felülírom, a Windows is tudjon már róla, hogy ha másik programra átváltok, akkor ugye azt újra kell festenie, meg az asztalt is. És természetesen, ha eleve az egész programablak teljes képernyős, és csak úgy felülírom mondjuk a fejlécét, attól még az egér működni fog, mondjuk ha a jobb felső sarokban az X-re kattintok hogy zárja be a programot. Tehát a csak úgy felülírás nem az igazi.

    Tabbed documents legyen-e? Alapvetően egyszerre csak 1 fájl látható, a jobb oldali, megnyitott fájlok listájából választanám ki ha másikra váltok, de tudnia kell azt is ha egymás mellett van 2 fájl, vagy alul és felül másik fájl van.

    Köszönöm.
    Mutasd a teljes hozzászólást!
abcd