Results 1 to 15 of 15

Thread: DevExpress | applicatie GUI omzetten

  1. #1

    DevExpress | applicatie GUI omzetten

    hallo hallo,

    Momenteel gebruik ik componenten van TMS software en de standaard in de IDE aanwezige componenten voor het bouwen van de GUI. Nu begin ik steeds meer tegen de beperkingen van de TMS componenten aan te lopen, bovendien ziet het er ook allemaal niet zo gelikt uit. Nu overweeg ik het om over te stappen naar DevExpress. Om een weloverwogen beslissing te kunnen nemen zou ik graag antwoord/feedback willen krijgen op de volgende vragen:

    1) Wat zijn de nadelen van DevExpress? Zijn ze bijvoorbeeld complexer in gebruik? Ik zag dat het quantumgrid van DevExpress een handleiding had van een slordige 4300 pagina's

    2) Ik heb het idee dat de component refactoring niet heel veel tijd hoeft te kosten, maar ik heb hier geen ervaring mee. In mijn applicatie gebruik ik het MVVM patroon waardoor de logica in mijn forms tot een minimum beperkt is. In totaal heb ik nu ongeveer 40 forms. Hoelang zou dit ongeveer duren? Zelf denk ik dat het binnen twee werkdagen zeker moet lukken, maar ik ben een optimistisch mens

    3) Zijn er andere component sets die ik zou moeten bekijken?

    4) In GExperts zit een replace component functionaliteit. Is het handig om dit gebruiken in deze situatie? Ik heb er wel wat ervaring mee, maar dat waren redelijk eenvoudige replaces. Mijn ervaring is dat als dit soort zaken verkeerd gaan het ontzettend veel tijd kan kosten om erachter te komen wat er mis is.

    Bij voorbaat dank

  2. #2
    Hi

    DevExpress heeft mooie componenten en ook behoorlijk aan de prijs. Prijs begint bij $ 599 tot $ 1499
    Uiteraard is dat relatief en naar gelang je de componenten gebruikt. Neem je de uitgebreide suite
    dan heb je vaak geen andere componenten van andere leveranciers nodig.

    In de leercurve moet je wel wat tijd steken om resultaat te behalen. Ik heb er ook naar gekeken en
    getest maar waarvoor ik het nodig had was het overkill.

    Ik gebruik nu http://www.alphaskins.com/
    Simpel en eenvoudig, weinig overhead op je .exe en voldoende templates voorhanden om te gebruiken.

    Greetz Peter

  3. #3
    Het DevExpress quantumgrid is waarschijnlijk het meest complexe component ooit. De leercurve is enorm stijl, en het is (of lijkt) soms onmogelijk om dingen voor elkaar te krijgen zonder de DFM te editen. Daarbij wordt je executable twee keer zo groot zodra je een keer bij een DevExpress component in de buurt bent geweest.
    Ik heb het voor het laatst gebruikt in Delphi7, en heb (oh joy) nog een keer een migratie van het "dxGrid" naar het "cxGrid" mogen doen. Ik zou zelf niet snel meer kiezen voor DevExpress. Het kan heel veel, maar eigenlijk té veel.

    We hebben hier de Woll2Woll Infopower grids, die tegenwoordig ook in uitgeklede versie bij Delphi zitten. Die kan ik in ieder geval ook niet aanraden. Er zit wat typisch gedrag in, op het randje van buggy, en ze zien er ook niet heel gelikt uit. Toch zou ik eerder voor een dergelijk simpel object kiezen dan voor DevExpress grid.

    Wat wellicht een handige manier is, is om je componenten te wrappen in eigen componenten, waarin je dan ook alleen het gedrag exposet dat je wilt hebben, en op de manier waarop je het wilt hebben. Dus eigenlijk een "adapter" maken voor het component. Het voordeel is dat je zo'n adapter kan implementeren voor je huidige TMS grid, en eenzelfde adapter (qua zichtbare properties) ook kunt mappen op een willekeurig ander grid. Je kan het gedrag van beide adapters dan helemaal op je gemak ontwikkelen en testen, en op het moment dat je wilt wisselen, kan je dat vrij eenvoudig doen (bijvoorbeeld met die GExperts tool). Het is wel een beetje een klus, maar het heeft als voordeel dat de impact op het moment van wisselen niet zo groot meer is, en ook dat je adapter alleen minimaal gedrag hoeft te exposen, waardoor je een (voor je applicatie) standaard-gedrag voor een grid kunt vastleggen, en geen wildgroei aan toegepaste functionaliteiten krijgt..
    1+1=b

  4. #4
    @mierlp

    Voor zover ik kan zien, biedt alphaskins weinig nieuwe componenten zoals bijvoorbeeld een planner, gantt of een flow diagram. Mis ik iets of is het meer bedoeld voor skins (dat doet de naam namelijk wel vermoeden)

    @GolezTrol

    Geldt die complexiteit alleen voor het quantum grid of voor alle devexpress componenten? Als ik zo snel even naar de mb's kijk van de help files, waarvan er 8 groter zijn dan 10 mb, vrees ik het ergste.

    Mijn voorkeur gaat wel uit naar een (commercieel) pakket. Ik heb zelf meerdere componenten geschreven, maar ik merk dat zodra het wat complexer wordt het veel rendabeler is om het gewoon te kopen. DevExpress ziet er, van alle componenten, wel echt het beste uit.

  5. #5
    Het is idd niet echt goedkoop, het enige dat ik kan zeggen dat het goed is en dat de support ongeëvenaard is (imho).
    Kijk maar eens op https://www.devexpress.com/Support/C...uestion/List/1 naar het aantal tickets dat ze elke dag beantwoorden, dit deel van de website is ook enorm handig om zaken in op te zoeken die je niet meteen weet.

    Er is denk ik een trial, ik zou zeggen installeer die en speel er even mee

  6. #6

  7. #7
    ik denk dat je met je mvvm model ook niet blij gaat worden met devex. Er gebeurt enorm veel in de component zelf en die wil om goed te werken ook meteen alle data in zijn cache hebben.

    Een klant van me gebruikt het in een project. Het ziet er goed uit, maar ik blijf het een enorm moeilijke component vinden om te gebruiken.

  8. #8
    @Delphiwizard

    Ik heb wel eerder gespeeld met de trials, maar mijn ervaring is dat je er pas echt achter komt als je een echte applicatie maakt. Zo kom ik nu bij TMS ook wat zaken tegen waar ik niet zo vrolijk van wordt die ik eerst niet had gezien.

    ik denk dat je met je mvvm model ook niet blij gaat worden met devex
    Wat zijn dan concreet de verschillen met bijvoorbeeld de standaard componenten? Ben je min of meer verplicht om business logica in je form te zetten met devexpress? PiSymbol heeft daar ook het een en ander over gezegd, maar ik heb geen idee hoe het conflicteert met bijvoorbeeld MVVM of eigenlijk iedere andere ontwerp waarbij je geen/zo min mogelijk business logica in je forms wilt hebben.

  9. #9
    Quote Originally Posted by luigi View Post
    Geldt die complexiteit alleen voor het quantum grid of voor alle devexpress componenten?
    Mijn ervaring is zoals gezegd wat verouderd, maar volgens mij zijn alle componenten bovengemiddeld complex. Alleen een tamelijk complexe editbox is nog steeds te overzien, terwijl met name het quantum grid wel echt bizarre proporties aanneemt. Ze hebben van die demo's waarin ze heel trots laten zien wat je er allemaal mee kan zonder een regel code te schrijven, maar daar zitten dingen bij die ik niet eens wil kunnen zonder code te schrijven. Mijnenveger, een complexe Excel simulatie... Ik weet niet of ze inmiddels al docker containers kunnen runnen binnen een cel, maar het zou me niets verbazen.

    Het hele component is heel modulair opgebouwd, en zo ook de property editors. Als je ergens een vinkje verandert, dan kan je een heel ander deel ineens niet meer vinden. Ik had destijds het gevoel dat er ook quirks in zaten, waardoor ik soms de property editor af moest sluiten, en soms zelfs in de dfm moest rommelen om überhaupt verder te kunnen. Ik heb meer dan eens de dfm-code van twee quantum grids zitten vergelijken in WinMerge om te proberen te verklaren waarom de ene anders werkte dan de andere. Met 8 lagen diep geneste properties is dat in de object inspector niet te zien.

    Ik ben het wel eens met je keuze om voor een commercieel component te gaan. Mijn opmerking over zelf schrijven, ging dan ook specifiek over het schrijven van een soort adapter, zodat je niet door je hele applicatie afhankelijk bent van het 3rd party component.

    Stel, je maakt bijvoorbeeld een TLuigiGrid. Eigenlijk is dat een compound component dat in zich een DevExpress QuantumGrid heeft, maar dat weet niemand. Aan de buitenkant zie je alleen een aantal basisproperties en methods die je van een grid zou verwachten. In je code (en als je het goed doet ook in je dfm), zie je al die magie van de quantumgrid niet terugkomen, en je komt dus ook niet zo snel in de verleiding om alle magische functionaliteit te pas en te onpas te gebruiken. Voor de gevallen waar dat toch nodig is, kan je het oorsponkelijke grid in de code exposen, maar dan nog blijft het een stuk eenvoudiger om later nog eens de standaardinstellingen van het grid applicatie-breed aan te passen, of zelfs om het grid te vervangen door een ander.

    Het is alleen wel een k*tklus, en ik moet bekennen dat ik dit plan zelf nog nooit in de praktijk heb uitgevoerd.
    1+1=b

  10. #10
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    9,732
    Zelf gebruik ik overigens VST in grid modus. Heeft ook zijn quirks, maar de beslissing was destijds op snelheid (de applicatie was synchroon).

    Af en toe gebruik ik TChart, maar ik merk dat ik zelf vaak wat teken in opengl. Met name over tchart heen tekenen, autoschaling en scrollen werkt dan beter.

    Maar ik zit in industriële, niet bureau applicaties natuurlijk

    Tis overigens de eerste keer dat ik negatieve dingen hoor over TMS. Doorgaans zijn mensen er redelijk positief over.

  11. #11
    Tis overigens de eerste keer dat ik negatieve dingen hoor over TMS. Doorgaans zijn mensen er redelijk positief over.
    Tussen TMS en DevExpress zit een redelijk groot prijsverschil, maar ook een groot kwaliteitsverschil. In devexpress zitten ook wat componenten die bij TMS een apart pakket zijn. Bijvoorbeeld flowcharts. Het is niet dat ik perse ontevreden ben over TMS. Ik vind de prijs kwaliteit eigenlijk wel goed.

  12. #12
    @GolezTrol

    Elk voordeel heeft zijn nadeel Persoonlijk heb ik liever iets meer opties dan minder. Het kost dan in eerste instantie wel wat meer tijd en geld, maar dat vind ik het meestal (als het doet wat ik verwacht) wel waard. Een tijd geleden ben ik door Benno in contact gekomen met het kbmmw framework wat ontzettend flexibel is en dat ook even kost om mee te leren werken. Ik ben in die tijd echter nooit tegen een beperking aangelopen en ik heb van tijd tot tijd echt wel gekke eisen.

    @Benno

    Is er ook een kbmmw specifieke reden waarom je niet voor DevExpress kiest?

  13. #13
    J.W. de Bokx
    Join Date
    Jun 2007
    Location
    Pijnacker
    Posts
    71
    Ik heb al vele jaren met verschillende versies van devexpress gewerkt, en ben er heel tevreden over.
    Het is (vind ik) goed van opzet en je kan makkelijk van losse stukjes eigen afgeleiden maken om er je eigen draai aan te geven.
    De hulp van hun is inderdaad ook erg goed, ze reageren snel en op hun site staan veel voorbeelden en uitleg over de componenenten.

    Maar ik werk er dan ook al vanaf bijne de eerste versies ermee en ben er in mee gegroeid.
    Helaas de laatste jaren had ik geen werkgever die er ook mee werkte...

  14. #14
    Ik heb zojuist een licentie aangeschaft Dus ik ga het meemaken.

  15. #15
    Is er ook een kbmmw specifieke reden waarom je niet voor DevExpress kiest?
    Nee dat niet. Wat mij niet aanstaat is die mega component die alles voor je doet. Ik hou daar niet van, daarom heb ik destijds voor kbmmw gekozen en niet voor bijvoorbeeld remobjects of datasnap.

    Ik vond het bv erg vreemd dat bv de detaildata of een filter in devex niet via een soort callbacks werkt waarbij je de logica op je datamodule hebt. Wat dat betreft zou een vst achtige aanpak mij meer hebben aangesproken.

    Zelf heb ik nu de fnc suite van tms. De eerste releases hadden nog wel wat issues, maar tms heeft dat opgelost. Ik probeer ook steeds meer op te letten om niet in een full lock-in te komen zitten met Delphi. KbmMW en de afhankelijkheid daarvan met delphi is de belangrijkste reden dat ik nog in mijn delphi maintenance investeer. Maar ook bij Kim spelen wat interessante projecten momenteel met een requirement voor linux, dus met een beetje mazzel gaat compatibiliteit met lazarus omhoog.

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
  •