Results 1 to 7 of 7

Thread: Interfaces m.b.t. GUI componenten mogelijk ?

  1. #1
    TDigitalTrain user Hans Brenkman's Avatar
    Join Date
    Mar 2002
    Location
    Weert
    Posts
    1,861

    Interfaces m.b.t. GUI componenten mogelijk ?

    Hoi

    Ik heb een frame dat erft 7 niveaus diep. Op het 4e niveau heb ik o.a. een ListBox staan. Daarvan kan ik je altijd maar 1 item selecteren. Nu wil ik op dat niveau i.p.v. een ListBox een CheckList hebben waarbij ik meerdere items kan selecteren, en dan dienen niveau 5 t/m 7 te erven met die CheckList met de GUI-componenten en functionaliteit die ik al heb. Ik weet dat je met een ListBox ook meerdere items kunt selecteren als je MultiSelect enabled hebt. Maar visueel wil ik juist onderscheid maken tussen die mogelijkheid: 1 of meerdere te selecteren.

    Nou kun je zeggen dat het ontwerp achteraf verkeerd is geweest, maar daar heb ik op dit moment niet zo veel aan. Beide componenten op het frame plaatsen en vervolgens de ListBox niet tonen en de CheckList wel of vise versa, is natuurlijk ook geen mooie oplossing. Beide ervende frames zitten dan met een component waar ze niets mee van doen hebben.

    Ik ben een beetje bezig geweest met interfaces in eigen classen. Mijn vraag is of dat zoiets ook kan met GUI? Afhankelijk van de interface "op de plek" van de ListBox c.q. CheckList creeër je het gewenste component run-time om vervolgens daar mee aan de slag te gaan, dat is het idee. Suggesties met een andere oplossing zijn welkom ...

    Click image for larger version. 

Name:	tree.jpg 
Views:	124 
Size:	42.9 KB 
ID:	8115
    Testen kan niet de afwezigheid van fouten aantonen, slechts de aanwezigheid van gevonden fouten.

    Het is verdacht als een nieuw ontwikkeld programma direct lijkt te werken: waarschijnlijk neutraliseren twee ontwerpfouten elkaar.

  2. #2
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Ik denk van niet. Interfaces bevatten geen code. Ze specificeren alleen de requirements waar een classe die de interface implementeert aan moet voldoen.

  3. #3
    Stijn Sanders develyoy's Avatar
    Join Date
    Jun 2008
    Location
    GentBrugge, Belgi?½
    Posts
    1,046
    O jee, forms en frames overerven, waar is de tijd! Ooit leek me dat een goed idee, en ik had het uitvoerig in een project uitgevoerd (ja misschien ook tot zes niveau's diep) en het leek goed te werken tot het uiteindelijk onwerkbaar was geworden. In theorie en in het begin ziet alles er goed uit, maar als je later nog grote wijzigingen aan tussenniveau's moet gaan doen of grote wijzigingen aan het grotere plaatje, kom je heel vreemde dingen tegen.
    Als je met een bestaand project zit, kan ik alleen maar adviseren om in je dfm's goed in de haten te houden waar welke "inherited" komt te staan en of je die echt wel nodig hebt.
    Als je met een nieuw project zit, zou ik adviseren om je 'klasse-structuur' van forms en frames heel erg plat te houden, en de verschillende forms op te bouwen uit een lijst van gewone frames, en een eigen structuur van 'lijstjes van frame classes' die je nodig hebt om de verschillende forms mee op te bouwen. (In een TScrollBox of TPageControl of een combinatie van beide).
    Of als je helemaal gek wil doen, een eigen structuur om forms mee op te bouwen en alle controls zelf in run-time mee op te bouwen en klaar te zetten. Je zul zien dat dit eigenlijk best wel mee valt en goed vooruitgaat, als je het goed doet. Het is namelijk in theorie precies wat Delphi aan de hand van dfm's ook voor jou doet.

  4. #4
    Waarom beslis je niet gewoon runtime welk van de twee componenten je aanmaakt? Dat is uiteindelijk ook wat je doet in je interface voorbeeld toch? Je zou in je frame een MultiSelect property kunnen opnemen die afhankelijk van de waarde een ListBox of CheckList toont.

    Ik ben het overigens helemaal met Develyoy eens dat frames overerven voor veel problemen kan zorgen. Zelf maak ik in dit soort situaties meestal zelf een component.

  5. #5
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Ik heb 5 niveaus voor een forms en frames, maar de meeste zijn relatief dun.

    1. Helemaal abstract.
    2. Basis implementatie
    3. camera voerend scherm (krijgt events voor live beeld)
    4. Basis implementatie van een scherm, soms ook verdeeld over twee niveaus
    5. Klant specifiek derivaat voor b.v. overriden defaults en andere klein polijst werk


    Sommige dingen zijn inmiddels wat achterhaald(camera voerend scherm zou netter via een registratie systeem kunnen gaan, aan de andere kant verandert het nooit, en is verervings keus het weer een paar handelingen minder bij aanmaken nieuw scherm)

    Veel problemen heb ik die 15 jaar niet gehad, behalve dat reparenten van TFrame's eng is, en frames hebben vaak wat resize issues.

  6. #6
    ik heb met het overerven van forms weinig problemen, behalve dat je soms na een poos tot de conclusie komt dat een eerdere keuze niet handig was. Maar dat is niet zo zeer een Delphi issue maar meer een ontwerp / voortschrijdend inzicht issue.

    Met frames heb ik altijd in no-time ruzie, die ontwijk ik dan ook waar mogelijk.

  7. #7
    Reader
    Join Date
    May 2002
    Location
    Holland
    Posts
    3,382
    Frames zijn er bij mij na enkele pogingen uitgegooid voor altijd.
    Visual form inheritance ook. Ik maak uitsluitend forms die afstammen van TCustomForm en altijd puur in code. Is wat werk, maar dan heb je alles in de hand.

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •