[VB.NET]Hoe formulier met veel tabbladen+controls maken

Pagina: 1
Acties:

Onderwerpen


Acties:
  • 0 Henk 'm!

  • Arie-Kanarie
  • Registratie: Juli 2004
  • Laatst online: 21-06 13:40

Arie-Kanarie

Een keer wat anders

Topicstarter
Ik ben bezig met het uitbreiden van een programma/scherm dat onderdeel is van een groot pakket (MDI)
Men kan hiermee artikelen onderhouden. Alleen kan men hier héél veel eigenschappen van een artikel onderhouden.
Dit heeft er voor gezorgd dat één en ander verdeeld is over diverse tabbladen. Redelijk overzichtelijk voor de klant alleen het ontwikkelen van de GUI gaat behoorlijk traag. Als ik de naam van een nieuw label wijzig moet ik ~10-20 seconden wachten voor ik volgende label kan wijzigen.
Voorbeeld van scherm: Afbeeldingslocatie: http://home.hccnet.nl/lheusinkveld/images/scherm_klein.jpg

Dat het zo traag is komt vast door de 5000 regels designer generated code die erachter hangt.
Maar hoe kan ik dit anders doen?
Voor elk tabblad een apart formulier maken met en panel erop en dan op runtime basis de inhoud van dat panel kopiëren naar een panel op het tabblad. Eventueel pas op het moment dat een gebruiker daadwerkelijk een tabblad kiest.
Ik ken ook wel usercontrols (althans de theorie, eigenlijk geen praktijk ervaring), maar is dat de/een oplossing hier?
Het is geen dagelijks programma, maar iets van deze grootte moet toch eerder (door iemand hier) gemaakt zijn?
Graag jullie tips/hints/schoppen in de goede richting.
Heb al wat gegoogled en ook al hier op tweakers gezocht, maar nog niets nuttigs kunnen vinden.

FYI: Voor de tabbladen en tekstboxen wordt gebruik gemaakt van ComponentOne en de buttons zijn ook een extern component.

[ Voor 4% gewijzigd door Arie-Kanarie op 07-01-2010 16:31 ]

Software ontwikkelen in de Achterhoek voor leuke klanten door heel Nederland? Klik hier


Acties:
  • 0 Henk 'm!

  • Niemand_Anders
  • Registratie: Juli 2006
  • Laatst online: 09-07-2024

Niemand_Anders

Dat was ik niet..

Bekijk anders eens Microsoft SmartClient Software Factory (te vinden op codeplex).

Programmeren gaat dan op de MVP/MVVM (soort van MVC voor desktop applicaties).
Er zijn meerdere mvp/mvvm frameworks, alleen is er erg veel documentatie te vinden over SmartClient.

Het komt er inderdaad op neer dat je meerdere panels zult maken en deze panels plaats op je op de tabbladen. Een inversion of control implementatie (Windsor containers, Ninject, StructureMap, Spring.net, etc) kan vervolgens je artikel entity propageren naar alle onderdelen van de form.

En ik neem aan dat alle properties al via twee-weg binding aan de controls worden gekoppeld, toch?

If it isn't broken, fix it until it is..


Acties:
  • 0 Henk 'm!

  • Haan
  • Registratie: Februari 2004
  • Laatst online: 09:42

Haan

dotnetter

Dat het zo traag is, zal ook wel liggen aan de hardware waar je op werkt? Wat zijn je systeemspecs?

Kater? Eerst water, de rest komt later


Acties:
  • 0 Henk 'm!

  • Arie-Kanarie
  • Registratie: Juli 2004
  • Laatst online: 21-06 13:40

Arie-Kanarie

Een keer wat anders

Topicstarter
Niemand_Anders schreef op donderdag 07 januari 2010 @ 17:34:
Bekijk anders eens Microsoft SmartClient Software Factory (te vinden op codeplex).

Programmeren gaat dan op de MVP/MVVM (soort van MVC voor desktop applicaties).
Er zijn meerdere mvp/mvvm frameworks, alleen is er erg veel documentatie te vinden over SmartClient.

Het komt er inderdaad op neer dat je meerdere panels zult maken en deze panels plaats op je op de tabbladen. Een inversion of control implementatie (Windsor containers, Ninject, StructureMap, Spring.net, etc) kan vervolgens je artikel entity propageren naar alle onderdelen van de form.

En ik neem aan dat alle properties al via twee-weg binding aan de controls worden gekoppeld, toch?
Ik zal daar eens naar kijken.

Nou het feit wil dat het programma uit cobol komt en dat het nu omgezet en uitgebreid wordt. Het is een (compleet) CRM pakket. Veel data zit dus ook nog in ouderwetsche cobol bestanden. Je kan het nauwelijks database noemen. Dus die twee-weg binding is er niet echt. Tenminste als ik jou juist begrijp ;-)
Zit wel een laag tussen zodat we in de .net code met objecten kunnen werken.
Maar je gaat vast lachen/huilen als je de logica achter de opslaan-knop ziet: alle properties van de objecten vullen en dan een write of rewrite (afhankelijk van of object al bestaat of niet).
Haan schreef op donderdag 07 januari 2010 @ 17:54:
Dat het zo traag is, zal ook wel liggen aan de hardware waar je op werkt? Wat zijn je systeemspecs?
Mwa, tis geen monster pc, maar slecht nou ook niet echt, tenminste vind ik.
Amd Athlon 64 X2 dual core 4200+ (een HP systeem) met 2 gb geheugen.
Misschien dat 4 gieg beter is, maar op een dergelijk systeem zou je toch gewoon met Visual Studio 2008 moet kunnen werken. Of loop ik nu heel erg achter?

Software ontwikkelen in de Achterhoek voor leuke klanten door heel Nederland? Klik hier


Acties:
  • 0 Henk 'm!

  • Laurens-R
  • Registratie: December 2002
  • Laatst online: 29-12-2024
Nee hoor je pc is prima :) Winforms staat er om bekend dat het behoorlijk vertraagd op het moment dat je met extreem veel controls aan de gang bent.

Maar even back2topic... Als je zoveel controls op je scherm nodig hebt zou ik het een en ander dynamisch op het scherm gaan toveren via een xml bestand met daarin de schermlayout en per veld een koppeling naar de betreffende COBOL koppeling?

Dat scheelt enorm veel werk, frustratie en vooral tijd op het moment dat je weer eens wat moet wijzigen. Het is misschien helemaal volgens een bepaald ontwerp princiepe/pattern, maar als je inderdaad wat beperkt in de opties bent is misschien handiger om het zo op te lossen. Het is maar een idee.

voorbeeld:

code:
1
2
3
4
5
6
7
<screen Name="Klanten">
   <Field name="Voornaam" Type="text" CobolField="voornaam"/>
   <Field name="Achternaam" Type="text" CobolField="achternaam"/>
</screen>

<screen Name="Iets anders">
...


Het is wat simpel neergezet, maar het gaat om het idee. Je kan bijvoorbeeld ook nog layout attributen toevoegen en ondersteuning toevoegen voor gecalculeerde velden etc....

Op deze manier hoef je alleen een XML element toe te voegen voor een nieuwe veld. Maar ja dan kan je in 1x je hele applicatie gaan herschrijven... en ik kan me voorstellen dat daar geen budget voor is ;) Aangezien het de hele architectuur ineens 180 graden de andere richting in stuurt.

[ Voor 53% gewijzigd door Laurens-R op 07-01-2010 23:29 . Reden: even wat anders geformuleerd. ]


Acties:
  • 0 Henk 'm!

  • RobIII
  • Registratie: December 2001
  • Niet online

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

(overleden)
EvilB2k schreef op donderdag 07 januari 2010 @ 23:20:
Als je zoveel controls op je scherm nodig hebt zou ik het een en ander dynamisch op het scherm gaan toveren via een xml bestand met daarin de schermlayout en per veld een koppeling naar de betreffende COBOL koppeling?
Ik denk dat je 't wiel opnieuw aan 't uitvinden bent en driftig op weg bent naar een afgrond waar je dreigt in te storten.

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Je eigen tweaker.me redirect

Over mij


Acties:
  • 0 Henk 'm!

  • DoDo
  • Registratie: Juli 2001
  • Nu online
Het beste wat je kan doen is elk "Tabblad" verdelen, en voor elk blad een Usercontrol aan maken.
Deze usercontrols kun je vervolgens weer in je tabblad inladen. Dit zorgt ervoor dat elk stukje in een ander bestand zit.

Het inladen van de usercontrols kun je dan vervolgens ook pas doen als hij nodig is in het scherm, waardoor je de applicatie waarschijnlijk een stuk sneller maakt.

Acties:
  • 0 Henk 'm!

  • jip_86
  • Registratie: Juli 2004
  • Laatst online: 08:27
Ik zou ook voor de opsplitsing in Usercontrols gaan. In eerste instantie per tabblad, maar wellicht nog wel kleiner. Of dat kan hangt wel van de applicatie af.

Acties:
  • 0 Henk 'm!

  • Arie-Kanarie
  • Registratie: Juli 2004
  • Laatst online: 21-06 13:40

Arie-Kanarie

Een keer wat anders

Topicstarter
DoDo schreef op vrijdag 08 januari 2010 @ 09:54:
Het beste wat je kan doen is elk "Tabblad" verdelen, en voor elk blad een Usercontrol aan maken.
Deze usercontrols kun je vervolgens weer in je tabblad inladen. Dit zorgt ervoor dat elk stukje in een ander bestand zit.

Het inladen van de usercontrols kun je dan vervolgens ook pas doen als hij nodig is in het scherm, waardoor je de applicatie waarschijnlijk een stuk sneller maakt.
en
jip_86 schreef op vrijdag 08 januari 2010 @ 10:03:
Ik zou ook voor de opsplitsing in Usercontrols gaan. In eerste instantie per tabblad, maar wellicht nog wel kleiner. Of dat kan hangt wel van de applicatie af.
Ik ga dat ook proberen, heb nu al een usercontrol gemaakt en op het tabblad gezet. Vandaag weer verder met testen of ik alles werkend kan krijgen.
Nog even over het inladen van de usercontrol(s) op het moment dat het nodig is... Doe ik dat door de
code:
1
MyUserControl1 = new UserControl1

pas (éénmalig) uit te voeren op het moment dat het tabblad geopend wordt?

Software ontwikkelen in de Achterhoek voor leuke klanten door heel Nederland? Klik hier


Acties:
  • 0 Henk 'm!

  • creator1988
  • Registratie: Januari 2007
  • Laatst online: 11-09 14:44
Dat zal niet zoveel uitmaken want pas als je component echt gerendered wordt gaat hij ook echt dingen tekenen. Initializeren kan je dus al eerder doen.
Pagina: 1