Results 1 to 15 of 15

Thread: Zoekscherm ontwerp

  1. #1

    Zoekscherm ontwerp

    Hallo hallo,

    In mijn applicatie heb ik momenteel ongeveer 60 tabellen/joins waarvoor ik een zoekschermen wil maken. Ik had als tijdelijke oplossing hiervoor ongeveer 60 pages + frames designtime op een pagecontrol gezet in één form. Dit werkte niet helemaal lekker. Het lijkt erg langzaam te worden naarmate er meer frames worden geplaatst. Zie mijn andere post. 60 pages + frames voelt ook niet echt als een elegante oplossing en Zoals John al aangaf is het niet echt een lekker ontwerp. De vraag is hoe dan wel? Voor iedere zoektype een form of misschien toch een frame maar deze runtime createn? Wat is wijsheid? Ik ben vast niet de eerste die zoek functionaliteit nodig heeft

    Bij voorbaat dank!

  2. #2
    Het is me niet helemaal duidelijk. Bedoel je dat je een zoekopdracht kan typen, die vervolgens over 60 tabellen (queries) verspreid wordt, en waarvan de resultaten in 60 verschillende tabs getoond worden?
    Een klein screenshotje met toelichting zou misschien wel helpen om te begrijpen wat je nou precies aan het bouwen bent.

    Vanuit een UI perspectief, hoe moet een gebruiker wijs worden uit 60 tabs, zeker als hij niet weet waar de informatie precies te vinden is?

    Daarbij kan ik me voorstellen dat dat traag is. Het klinkt alsof je 60 queries aan het uitvoeren bent. Kan het zijn dat die al per ongelukt uitgevoerd worden voordat je een zoekopdracht hebt? Dat zou het trage openen ook wel verklaren.

    Ik zou het zoeken zelf naar threads verplaatsen. Na het uitvoeren van een zoekquery kan je de resultaten tonen.

    Voor het tonen van die resultaten lijkt het me persoonlijk prettiger om gewoon een lijst te hebben dan 60 tabbladen met lijsten, maar dat is misschien persoonlijke smaak.
    1+1=b

  3. #3
    En als je dan al 60 verschillende tabs zou hebben dan moet je die natuurlijk pas vullen wanneer de gebruiker er daadwerkelijk op klikt. Niet al van te voren. Anders is het een waste of resources.

    Maar een wat duidelijkere uitleg of screenshotje kan veel duidelijk maken.

    Ik zou ook eerder aan een lijst denken met 60 items waaruit de gebruiker kan kiezen en die dan laten zien. Eventueel links de lijst en rechts het resultaat (die je dan maakt op moment dat er links iets gekozen wordt).

  4. #4
    Het is me niet helemaal duidelijk. Bedoel je dat je een zoekopdracht kan typen, die vervolgens over 60 tabellen (queries) verspreid wordt, en waarvan de resultaten in 60 verschillende tabs getoond worden?
    Nee dat bedoel ik niet. Wat ik wil is dat als iemand bijvoorbeeld een bepaalde factuur zoekt, dat dit kan op factuurnummer, factuurdatum e.d. Bij een zoek opdracht naar een klant kan dit bijvoorbeeld op klantnummer, postcode etc. zijn. Het zoekscherm verschilt dus afhankelijk van waar naar gezocht wordt.

    Daarbij kan ik me voorstellen dat dat traag is. Het klinkt alsof je 60 queries aan het uitvoeren bent. Kan het zijn dat die al per ongelukt uitgevoerd worden voordat je een zoekopdracht hebt? Dat zou het trage openen ook wel verklaren.
    Ik gebruik kbmmw voor dit project en daar zit een logfunctie in die naar de EventLog in de IDE logt hier zie ik geen activiteit (geen datatverkeer tussen client en server) tijdens het openen van het zoekscherm.

    Ik zou het zoeken zelf naar threads verplaatsen. Na het uitvoeren van een zoekquery kan je de resultaten tonen.
    Ja dat gebeurd ook al.

    Voor het tonen van die resultaten lijkt het me persoonlijk prettiger om gewoon een lijst te hebben dan 60 tabbladen met lijsten, maar dat is misschien persoonlijke smaak.
    De tabbladen hadden alleen als functie om de juiste zoek invoer velden te tonen. De tabs zelf waren niet zichtbaar.


    Hoe bouw jij dan een zoekscherm GolezTrol?

    1) Doe je dit designtime of runtime

    2) Gebruik je per type (factuur, order) één form of pak je het op een andere manier aan.

  5. #5
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    Ik 'zie' hier een aparte class, waarin de frames vermeld staan en als 1 van de 60 nodig zijn deze @runtime aanmaken en tonen vanuit de class.
    Delphi is great. Lazarus is more powerfull

  6. #6
    Dus frames designtime ontwerpen en runtime createn en dat alles in één form? Of begrijp ik je verkeerd?

  7. #7
    Ik zou helemaal niet met frames werken. Ik zou alles run-time opbouwen.

    Zoiets:
    Click image for larger version. 

Name:	SFRmOL9.png 
Views:	147 
Size:	11.9 KB 
ID:	7762

    Links kun je dan kiezen voor de tabelsoort. Je kunt daar "onder water" (lees: in code) een bepaalde SQL (kan ook een join e.d. zijn) aanhangen. Bovenin het rechter gedeelte kun je dan nog als filter wat gegevens opgeven. Dit gedeelte bouw je iedere keer run-time op a.d.h.v. de keuze die je links gemaakt hebt. En onder komt dan de DBGrid met het resultaat.

    Het run-time opbouwen vergt wel wat meer werk maar het is flexibeler als je er een item bij wilt zetten.

  8. #8
    Okay dat is helder Volgens mij heb ik het weer eens te moeilijk gemaakt voor mezelf

  9. #9
    Aangezien al je zoekschermen los staan van elkaar, zie ik eerlijk gezegd niet in waarom het één scherm zou zijn. Je hebt een klantzoekscherm, of een orderzoekscherm, of een ....
    Wat je nu hebt is één scherm waarin alle mogelijke manieren van zoeken zijn gedefinieerd, terwijl je toch maar één ervan tegelijk gebruikt.

    Ik neem aan dat je dat voor andere schermen ook niet doet, of heb je een enkel edit-scherm met daarin tabs voor klant, factuur, order, enz?
    1+1=b

  10. #10
    Daar valt zeker ook wat voor te zeggen.

    Ik neem aan dat je dat voor andere schermen ook niet doet, of heb je een enkel edit-scherm met daarin tabs voor klant, factuur, order, enz?
    Nee, dat doe ik voor andere schermen niet.

  11. #11
    Wat je nu hebt is één scherm waarin alle mogelijke manieren van zoeken zijn gedefinieerd, terwijl je toch maar één ervan tegelijk gebruikt.
    Niet als je ze run-time aanmaakt

    Ik gebruik een frmBoek (wat één basis formulier is) voor debiteuren, crediteuren, offertes, orders, facturen, landen, branches etc. etc. etc. Maar in designtime bevat dit scherm alleen maar een DBGrid, een toolbar en een leeg zoekpanel aan de rechterkant. Afhankelijk van de soort worden deze gevuld met de juiste gegevens en filter-velden. Run-time opgebouwd. Ik vind dit fijn omdat ik een regel er zo bij kan zetten zonder in design-time de hele boel overhoop te gooien. Ik kan ook een regel onzichtbaar maken (of gewoon niet aanmaken) en alle andere velden schuiven dan op naar boven. Probeer dat maar eens in design-time te doen met een TEdit.

    Voor de werkelijke edit heb ik dan weer een ander formulier (frmStambestand) met een toobar en een TPageControl. De TPageControl is compleet leeg en wordt ook run-time opgebouwd met de juiste TDBEdits.

    Het opzetten van dit geheel was wel even werk maar zeker ook omdat je dus met de velden in run-time kunt spelen (wel/niet zichtbaar e.d.) was mij dit wel waard.

    Toen ik er ooit mee begonnen was, was ik zo aan het klooien met input-velden en het juist uitlijnen daarvan, dat ik er helemaal gek van werd. En toen moest er weer een veldje toegevoegd worden Toen besloot ik al vrij snel voor dit "framework".

    (En in een ander topic kon je ook zien dat ik met één regel het hele lettertype kan wijzigen van alle forms.)

  12. #12
    Niet als je ze runtime aanmaakt nee, maar dan nog is het de vraag of het handig is om alles op 1 form te zetten. Als je frames maakt voor de verschillende zoekopdrachten, dan kan je het juiste frame op het zoekpaneel zetten.

    Maar als je geen zoekpaneel hebt, maar een apart zoekscherm, is het het dan waard om kunst- en vliegwerk te verrichten om alles in één scherm te krijgen? Of je gaat alles runtime opbouwen, of je hebt een 60 frames waarvan je runtime de juiste gaat selecteren voor op je form, maar wat heb je dan gewonnen t.o.v. 60 forms (zonder aparte frames)?
    1+1=b

  13. #13
    Quote Originally Posted by GolezTrol View Post
    Niet als je ze runtime aanmaakt nee, maar dan nog is het de vraag of het handig is om alles op 1 form te zetten.
    Als je alles runtime aanmaakt zet je dus niet "alles" op 1 form. Je zet alleen die zoekvelden op je form die je daadwerkelijk nodig hebt (in een zoekpanel). Dat dat toevallig op een "basis"-form is maakt niet zoveel uit.

    Als je frames maakt voor de verschillende zoekopdrachten, dan kan je het juiste frame op het zoekpaneel zetten.
    Als je de frames (of forms) met velden al hebt, en je weet dat er niets wijzigt en geen meer bijkomen, dan kun je dat wel zo doen. Maar als je op 10 frames een veldje tussen moet voegen... dan is dat geklungel met alles opschuiven e.d. (vind ik). Ik heb het designtime ontwerpen nooit zo handig gevonden maar dat ligt waarschijnlijk aan mij.

    In ieder geval heeft me dat met het hele dpi en font gebeuren heel wat kopzorgen bespaard.

  14. #14
    ik gebruik vaak iets vergelijkbaars als Luigi, alleen gebruik ik bij voorkeur geen frames maar forms. De forms maak ik uiteraard designtime aan, maar worden @runtime alleen gemaakt als ze nodig zijn. Die forms hebben geen border en zet ik meestal op een panel.

    Voor mij werkt dat over het algemeen prima en vlot.

  15. #15
    John Kuiper
    Join Date
    Apr 2007
    Location
    Almere
    Posts
    8,747
    +1

    Met forms heb ik iets meer speling dan met frames.
    Overigens zijn die 60 frames niet verspillend, zolang ze @runtime worden uitgevoerd,
    Delphi is great. Lazarus is more powerfull

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
  •