06. september 2002 - 18:52Der er
8 kommentarer og 2 løsninger
Syntax i MS VC vs. BCB ?
Jeg er netop gået fra BCB til MS VC (da mange herinde opfordrede til det). Men hvordan er syntaxen i MS VC i forhold til BCB ? Jeg tænker specielt på når man i BCB skrev Label1->Caption, hvad gør man i MS VC ?
Derudover har jeg hørt at man skal skrive alt muligt for at oprette et simpelt objekt, nogen der ved noget om det ?
Hvis du anvender MFC, vil syntaxen som regel være: m_Label = "Text"; forudsat du har en membervariable kaldet m_Label naturligvis...
Dit andet spørgsmål måtte gerne være lidt mere specifikt, hvad er , i dine øjne, "et simpelt objekt" og "alt muligt"?
Til tider skal man skrive mere for at udføre en bestemt handling (det går sikkert også den anden vej), men det skyldes, mener jeg, at VC++ ofte definerer nogle skarpere objektorienterede skillelinier. Altså gør det ofte designet mere robust...
jpk >> I BCB kan man lave rigtigt meget ved bare at trække nogle VCL-komponenter ned på sin form, og så stille på de forskellige properties. Two-Ways IDE'en gør at man automatisk får dannet tilhørende kode, når man designer sit GUI.
På den måde er det meget enkelt at lave "simple objekter" - at lave en Open File dialog f.eks. kræver kun at man dropper en komponent og dernæst i sin OnClick event skriver OpenDialog1->Execute();
Fra det jeg har set her på eksperten, skal man "skrive alt muligt" f.eks. omkring en open dialog - noget som er meget simpelt i BCB. (I BCB laves f.eks. intet MESSAGE_MAP i sourcen, og alle de tomme AFX klasser har vi heller ikke - sourcen indeholder *KUN* det vi har lavet noget ekstra til eller ændret på.)
nubi19 >> Meget af det jeg har set, er der en 1:1 sammenhæng mellem MVC og BCB hvis vi snakker standard/Windows relaterede componenter, forstået på den måde at det som du i BCB kan bruge med 'T' foran, kan du i MVC bruge med 'C' foran:
TLabel = CLabel TThread = CThread
osv. Du har (selvfølgelig) ikke nogen af VCL-komponenterne i MVC - men du kan sikkert ofte finde den oprindelige Windows API og interface til den i stedet. Mange af tingene kommer du igennem vha. Wizards - herunder også at oprette membervariabler. (Så vidt jeg husker at have læst.) Der *skal* skrives mere - men mange af de egenskaber du styrede på designtidspunktet i BCB, kan du styre fra programmet i MVC:
BCB: Label1->Caption sættes på designtidspunktet til "Text"
MVC: m_Label = "Text"; i selve koden til initializer.
(Du skal gøre noget ekstra for at få dannet denne "membervariable" - noget med en wizard - jeg kan ikke huske hvad, men det ved jpk !)
BCB "gemmer" meget af det vi laver i .DFM filerne (forms) - der gemmer MVC tilsvarende information i .RC filen (ressource file) I BCB kan man ikke rigtigt "se" hvordan formens forskellige komponenter dannes (det har man så heller ikke rigtigt noget at bruge til), det er så tilgengæld skrevet helt ud i MVC (iøvrigt ligesom man gør i JAVA):
int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct) { if (CFrameWnd::OnCreate(lpCreateStruct) == -1) return -1;
if (!m_wndToolBar.CreateEx(this, TBSTYLE_FLAT, WS_CHILD | WS_VISIBLE | CBRS_TOP | CBRS_GRIPPER | CBRS_TOOLTIPS | CBRS_FLYBY | CBRS_SIZE_DYNAMIC) || !m_wndToolBar.LoadToolBar(IDR_MAINFRAME)) { TRACE0("Failed to create toolbar\n"); return -1; // fail to create }
if (!m_wndStatusBar.Create(this) || !m_wndStatusBar.SetIndicators(indicators, sizeof(indicators)/sizeof(UINT))) { TRACE0("Failed to create status bar\n"); return -1; // fail to create }
// TODO: Delete these three lines if you don't want the toolbar to // be dockable m_wndToolBar.EnableDocking(CBRS_ALIGN_ANY); EnableDocking(CBRS_ALIGN_ANY); DockControlBar(&m_wndToolBar);
return 0; }
I BCB ville der i MainFrame's constructor formentlig blot have stået:
Du har ret i, at der generelt står mere kode i VC++, hvor det, til sammenligning, er gemt væk BCB. Jeg kan sagtens forstå at mange synes dette gør BCB mere simpel at arbejde i. Det handler jo egentlig nok om hvordan man foretrækker sit udviklingsmiljø skal opføre sig samt hvad der skal være tydeligt og hvad der skal være gemt af vejen. Udviklingsmiljøet repræsenterer jo ikke blot et grafisk user interface, men et udviklingsidiom! Jeg tror også mange af de debatter der i tidens løb har været her på Eksperten, om hvordan netop de to miljøer er indbyrdes forskellige, skyldes mangel på kendskab… Jeg foretrækker (som du jo ved) VC++ og kender som følge deraf naturligvis også dette miljø bedst. Derfor ligger det ligefor, at jeg mener det er det letteste at bruge. Tro mig når jeg siger, at det sidste jeg ønsker, er at deltage i endnu en religionskrig. Jeg siger ikke at det ene program er bedre end det andet, kun at det ene program *passer* bedre til mig…
Du nævner hvordan man bærer sig ad med at oprette nogle forskellige objekter, her vil jeg naturligvis gerne beskrive fremgangsmåden i VC++…
- Komponenter Man vælger at indsætte en komponent (fx MediaPlayer) og der genereres automatisk en klasse til at håndtere den. Man kan ligeledes stille de tilhørende proporties for komponenten på en dialog. Som du skriver, kan man også gå direkte på interfacet (hvilket jo også giver en bedre hastighed og mindre memory footprint), men dette er altså på ingen måde et krav. VC++ kan også generere en sådanne wrapper classes for dine egne komponenter.
- Fildialog En simpel fildialog kan oprettes og vises således: CFileDialog dlg(true); // opret objekt dlg.DoModal(); // vis dialog På mit arbejde har jeg til tider brug for at lave specialiseringer af fx åben/gem dialogerne (tilføje ekstra kontroller), jeg kunne godt tænke mig at vide hvordan det fungerer i BCB?
- Membervariable Dette synes jeg er en genial feature, da den fjerner mange af de kedelige opgaver i forbindelse med dataoverførsel mellem dialoger og datastrukturer. Man skal ganske rigtig lave lidt (meget lidt) arbejde for at oprette en membervariabel: 1) Højreklik på en kontrol og vælg ClassWizard (eller bare tryk Ctrl+W). 2) Tryk ”Add Variable” (eller dobbeltklik på ID’et) og vælg så type og skriv et navn på dialogen der kommer frem. VC++’s funktioner til at håndtere membervariable laver den nødvendige konvertering mellem variable og kontroller. Fx kunne man jo have et heltal, som brugeren kan ændre i en edit box. Med en ENKELT linie kode (som wizarden genererer) kan man foretage konverteringen fra int til tekst OG fra tekst til int. Det bedste ved det hele er, at det foregår over et rent og tyndt lag så man får en rigtig god separation. Altså slut med at lave kode som: Int nVal = atoi(Label1->Caption); Denne teknik kalder MS for DDX (Dialog Data Exchange) og den kan også bruges i mere avancerede tilfælde og er i øvrigt let at bruge med sine egne specialiseringer af kontroller. For nyligt har jeg fx anvendt DDX på en class CCheckComboBox (fundet på nettet), der som navnet antyder er en combo box med tilhørende check button til hvert element. Hvis en instans af comboen indeholder 6 elementer, A, B, C, D, E, F kan jeg ”checke” min combo’s elementer således: DDX_CBStringCheck(pDX, ID_COMBO, m_strChecked, m_Combo); Hvor m_strChecked fx kan indeholde ”A,B,F”. Vælger man at lade wizarden tilføje endnu en linie, kan man anvende DDV (Dialog Data Validation). Tager vi ovenstående eksempel med en int, kan linien: DDV_MinMaxInt(pDX, m_nMyVal, 0, 5); Validere værdien (skal være mellem 0 og 5), vise en fejlmeddelelse hvis kravene ikke er opfyldte samt sætte focus til det felt der indeholder en ugyldig værdi.
jpk >> Det med DDX og DDV er ganske fikst, det skal man lave selv i BCB - men hvordan "ser" man kontrollen ? Jeg har i mit MVC 6.0 lavet en simpel MDI applikation vha. 'New ...' og 'MDI application' - men jeg kan ikke komme til at se formen nogen steder (JEG kan ikke, men MAN kan sikkert - jeg kan simpelthen bare ikke finde ud af hvordan man gør.)
jpk >> Iøvrigt har du helt ret mht. religion og BCB versus MVC.
Men - MVC er jo uden diskussion den version af de to der anvendes mest ude i "virkeligheden". Vi anvender godt nok C++ Builder der hvor jeg er til daglig, men principielt kun fordi det ligger så tæt på Delphi som vi havde gang i i forvejen - og så er/var det meget billigere at komme i gang med.
I dag hvor vi samarbejder med virksomheden som f.eks. laver Windows CE applikationer, ville det klart have været en fordel at vi havde anvendt MVC til vore prototyper - så kunne man have bygget direkte videre på dem.
Hvis man derfor kender C++ og har mod og penge til det (læs mulighed for lige at bruge lidt ekstra tid i starten på at komme ind i MVC) samt pengene til det, vil jeg OGSÅ anbefale MVC.
I VC++ tænker man typisk ikke på indholdet af et vindue som en "form". En SDI/MDI app har views, der ofte er meget dynamiske (jeg forbinder ordene dialog og form med noget mere statisk). Hvis du vil lave et view, hvorpå du kan sætte edit boxes, combo boxes osv. kan du vælge et CFormView (default er CView), i wizarden når du opretter dit projekt.
Jeg tror du rammer plet med din antagelse om at VC++ har en stejlere indlæringskurve, det er lidt ærgeligt... Jeg synes ofte folk prøver at gå over åen efter vand, når de bruger VC++. Vil man fx lave en Stifinder-lignende app, kan man jo let give sig til at (programatisk) indsætte en CTreeCtrl i et view, det virker jo meget naturligt, ikke? Men man kunne jo også bare bruge et CTreeView, så er man næsten færdig før man er begyndt... Jeg tror det er enormt vigtigt at man får fat i hvordan MS's doc/view arkitektur ser ud, det letter arbejdet meget...
Well jeg har faktisk MVC, ellers dvs. jeg har studio .net som den skulle være med i, right ? En bekendt fejlkøbte det og solgte det uhyre billigt til mig :) Mht. alm. C++ så vil jeg ikke påstå at være expert i det, men jeg synes da det er til at finde ud af. Mange tak begge 2 for jeres hjælp, blot en sidste ting: I kender ikke en bog eller tutorial til MVC ?
Oki det vidste jeg ikke, har slet ikke pakket det op endnu :) Så endnu engang mange tak, i får lige 5 point hver :)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.