[Delphi] procedures uit je main-unit op nemen in een unit?

[mister X630]

Goedemorgen,

Ik heb een applicatie waaronder een aantal units hangen. Dit heb ik (al zeg ik het zelf) redelijk mooi modulair opgebouwd. Alleen 1 ding kom ik nog steeds niet uit en vraag ik me af of het uberhaubt wel kan.

Ik wil de de procedures die onder de main-unit hangen, bijvoorbeeld de ondrawColumnCell van een Grid die op het hoofdform van de applicatie staat, onderbrengen aan de unit waar het bij hoort.

Hoe pak ik dit aan als dit kan?

Ik wil dus zodra ik een unit opneem in een nieuwe applicatie niet al die losse procedures moeten hangen onder de main unit. (OnDrawColumnCell, OnClick, OnDblClick, etc. etc.)

Ik hoop dat het duidelijk is wat ik bedoel.

[MicroWhale]

Voor OnDrawColumnCell weet ik geen oplossing, maar voor OnClick, etc... kun je Actions gebruiken.

1. maak een DataModule,
2. Sleep een ActionManager (of ActionList) op de DataModule,
3. Maak een Action aan,
4. Vul de Naam, OnExecute, etc...
5. voeg de datamodule-unitnaam aan de uses-clause van de MainForm,
6. Selecteer bij een knop op de mainform de actie uit de DataModule. (in de dropdown staan de acties onder DataModule1.Action1, etc...).

Actions zijn zowiezo te prefereren. Zo kun je de GUI van de business-logic laag scheiden.

[whoami]

Zowiezo hoort de OnDrawColumnCell -imho- bij de code van je main-form. Het is nl. een eventhandler voor de DrawColumnCell event van de Grid die op je form staat.
Wat je natuurlijk wel kan doen, is de method die de daadwerkelijke code bevat die in die OnDrawColumnCell moet komen, in een andere unit gaan plaatsen.

Maar, nu vraag ik me af; waarom wil je dit zo doen ? Waarom wil je die event-handlers (OnClick, etc...) ergens anders gaan plaatsen ? Zo ga je toch veel van het overzicht verliezen ? En verlies je dan het gemak van je IDE niet ?

[MicroWhale]

Inderdaad, de OnDrawColumnCell hoort imo ook gewoon bij je GUI. De code hiervoor zou bij hierbij moeten blijven staan. Een omleiding naar een procedure in een andere unit kan alleen maar verwarring veroorzaken.

Het plaatsen van Actions in een andere unit is echter wel te verdedigen. Zo kun je grote functiegroepen separaat beheren. Als je je DataModules dan "Selections", "Formulas", "SmallDialogs", "Plugins" ,etc... noemt, weet je altijd waar je bepaalde functionaliteit moet/kan zoeken.

[mister X630]

waarom ik dit wil? ik heb allerlei lossen units geschreven. Bijvoorbeeld relaties en leveranciers. (ik noem maar wat)

Als ik nu een nieuwe applicatie maak dan importeer ik deze 2 units. Ik koppel het relatiegrid en het leveranciersgrid van het main form aan de pointers in de bijbehorende units en alles werkt gelijk. Behalve dan dat ik de losse procedures (onclick, ondblclick, etc. etc.) los moet typen of kopiëren/plakken uit een andere applicatie. Ik vind dat vreemd. Ik moet het toch zo kunnen maken dat als ik de unit importeer dat dan alles (of zo goed als alles) werkt.

Nu moet ik zoeken naar wat voor een "losse" code ik ook alweer allemaal in een applicatie gehangen heb wat hoort bij een bepaalde unit. (dus alles code achter de controls (Grids, buttons, etc.) op het tabblad relaties of leveranciers.

(bedankt voor de actionlist tip, ik zal eens kijken...)

[ Voor 19% gewijzigd door mister X630 op 14-02-2007 08:57 ]

[MicroWhale]

Als je alle functionaliteit van een formulier op het main-form wil gooien, kun je beter het hele formulier ín een panel op het main-form gooien.

Hieronder een voorbeeld:

Delphi:

  frmDbView:=TfrmDbView.Create(Form1);
  frmDbView.Dock(Panel1,Panel1.ClientRect);
  frmDbView.Show;
  frmDbView.OnChange:=UpdateStatusBar;

Het te docken form moet hiervoor wel "DockSite = True" hebben.
en een Alignment = alClient is ook wel handig

(N.B. Het gebruik van Actions voor het splitsen van GUI en BL is nog steeds wenselijk)

[ Voor 4% gewijzigd door MicroWhale op 14-02-2007 09:05 ]

[mister X630]

MrWilliams,

Dat zou dus betekenen dat ik dan 2 .pas en 2 .dfm files per unit krijg?
1 setje voor docking in de main applicatie. (waar dus een grid en buttons op staan) en een .pas voor de code achter het grid en de buttons.

en de andere .pas en .dfm zijn dus het "popupform" + code die bij het openen van bijvoorbeeld een relatie naar voren komt. (het form waar je dus het adres wijzigt of zo)

bedoel je het zo?

[MicroWhale]

imo (zoals je het schetst) begrijp ik het volgende:

1. een main form (.dfm & .pas),
2. een docking form (.dfm & .pas) dat in het main-form gehooked wordt,
3. een dialoogvenster (.dfm & .pas) dat geopend wordt als nodig.

Je lost er trouwens weinig mee op, tenzij je het te docken form en bijbehorende functionaliteit ook in andere apps gebruikt.

[ Voor 22% gewijzigd door MicroWhale op 14-02-2007 09:20 ]

[mister X630]

MrWilliams schreef op woensdag 14 februari 2007 @ 09:19:
imo (zoals je het schetst) begrijp ik het volgende:

1. een main form (.dfm & .pas),
2. een docking form (.dfm & .pas) dat in het main-form gehooked wordt,
3. een dialoogvenster (.dfm & .pas) dat geopend wordt als nodig.

juist! zo bedoelde ik het. Dat is toch wat jij bedoelt?

[MicroWhale]

ja, maar wat los je hier mee op?

[mister X630]

MrWilliams schreef op woensdag 14 februari 2007 @ 09:21:
ja, maar wat los je hier mee op?

Nu moet ik zoeken naar wat voor een "losse" code ik ook alweer allemaal in een applicatie gehangen heb wat hoort bij een bepaalde unit. (dus alles code achter de controls (Grids, buttons, etc.) op het tabblad relaties of leveranciers bijvoorbeeld.

Dat hoeft zoals jij het zegt niet meer. toch?

Hoe doe jij dat dan met de code die rechtstreeks aan je mainform hangt en je wilt een bepaalde unit weer hergebruiken in een andere applicatie? Ga je dan alles uitspitten om uit te zoeken wat er ook al weer allemaal bijhoorde? Dat moet op 1 of andere manier toch te organiseren zijn? (en dat gebeurd wel netjes met jou idee over het docken van die forms op een panel)

[Creepy]

Het lijkt me sterk dat je GUI code in je events 1 op 1 wilt hergebruiken in andere applicaties. Als er code in je events staan die je wilt hergebruiken dan kan je deze code beter los verplaatsen naar een andere unit (dus niet het event zelf!).

Als je in je events bijv. code hebt zitten die bijv een button er anders uit laat zien dan kan je hier beter een eigen nieuwe button van maken zodat je deze overal kan hergebruiken.

[MicroWhale]

@mister X630 Het klopt wel wat je zegt. De code (van relatie en leverancier) die voorheen in één form zit, wordt verdeeld over meerdere forms die elk één onderdeel behandelen (relatie óf leveranciers).

Hoe ik het meestal heb?

Losse TNotifyEvents heb ik niet in een formulier. Ik gebruik ActionManager om code aan te maken die iets doet. Eventueel in een DataModule. Deze dient als koppeling tussen GUI en BL. Dit is makkelijk als je een compleet andere gui krijgt. Hoef je alleen alle actions aan een GUI-element te hangen. Je weet dat de action werkt, dus je hoeft je geen zorgen te maken dat er door de GUI wat omvalt.

[schoene]

Je kan een standaardscherm maken, die de gewenste look-and-feel heeft, waar reeds een grid op staat, en alle schermen die dan een grid moeten hebben, laten overerven van dit scherm.
Als je de look-and-feel wil wijzigen, moet je dit dan enkel in dit standaardscherm doen.

[Tomatoman]

mister X630 schreef op woensdag 14 februari 2007 @ 09:31:
[...]
Nu moet ik zoeken naar wat voor een "losse" code ik ook alweer allemaal in een applicatie gehangen heb wat hoort bij een bepaalde unit. (dus alles code achter de controls (Grids, buttons, etc.) op het tabblad relaties of leveranciers bijvoorbeeld.

Ga naar het desbetreffende form, rechtsklikken en kies vervolgens in het popupmenu 'View as Text'. Nu zie je precies alle non-default properties en events van het form en de componenten die daarop staan. Je kunt weer terug naar het form door in het popupmenu van het form in teksweergave het menu-item 'View as Form' te kiezen.

De oplossing voor je probleem is trouwens heel eenvoudig: gebruik frames. Je kunt meerdere frames op een form plaatsen, terwijl ieder frame zijn eigen unit heeft.

[ Voor 10% gewijzigd door Tomatoman op 14-02-2007 13:15 ]

[MicroWhale]

tomatoman schreef op woensdag 14 februari 2007 @ 13:12:
[...]
De oplossing voor je probleem is trouwens heel eenvoudig: gebruik frames. Je kunt meerdere frames op een form plaatsen, terwijl ieder frame zijn eigen unit heeft.

ghehe.... frames zijn inderdaad wel leuk, maar ze geven Delphi 2006 zoveel te doen dat je met een beetje overerving en frames in frames soms een minuut zit te wachten totdat je mainform in de editor staat. Ook krijg je bij overerving problemen als je dingen gaat veranderen en moet je je frame aan het component palette toevoegen.

[Verwijderd]

ghehe.... frames zijn inderdaad wel leuk, maar ze geven Delphi 2006 zoveel te doen dat je met een beetje overerving en frames in frames soms een minuut zit te wachten totdat je mainform in de editor staat.

Troost je, UserControls (het Frame equivalent van VS2005) in C# hebben hetzelfde euvel.
Ben ooit zo slim geweest om 5 UserControls op een form te gooien die ieder ook weer 7 UserControls bevatten (5 rows met 7 cellen per row om een 5-weeks overzicht te presenteren). Runtime werkt dat prima en snel genoeg, maar designtime is 't "behelpen"...
't Hielp ook niet echt dat die cellen inheritten van een base UserControl.