Καλησπέρα. Θα ήθελα τη γνώμη σας για κάτι. Εχω  την "βιβλιοθήκη" της Infragistic και σκέφτομα πριν ξεκινήσω την ανάπτυξη μιας νέας εφαρμογής να κάνω subclass όλα τα control που θα χρησιμοποιήσω σε ένα assembly. Οι εφαρμογές μου δεν θα χρησιμοποιούν απ'ευθaείας τα control της Infrgistic αλλά τα subclassed control. Στο ιδιο assembly θα έχω και πχ ενα windows form. Ολα τα παραπάνω για να μπορώ πολύ έυκολα στο μέλλον να αλλάξω συγκεκριμένες ιδιότητες συνολικα στην εφαρμογή μου από ένα σημείο. Σκέφτεσται κάτι καλύτερο; Επίσης προσπαθώ να κάνω add σε inherited control επιλέγω το assembly στο οποίο βρίσκεται και δεν το φαιρνει καθόλου. Σε κάποια άλλα control (WinChart) δουλεύει κανονικά. Αυτό θα το ήθελα για να μπορώ πολύ εύκολα από τον Designer και όχι απο κώδικα να αλλάζω propertys του control.

Ευχαριστώ
Μάκης

Το παραπάνω δεν αφορά μονο την Infragistic είναι μάλλον αρχιτεκτονικό θέμα. Γενικά είναι καλύτερο να κάνουμε inherit όποιο control (και όχι μόνο) θέλουμε να χρησιμοποιήσουμε και να το προσθέσουμε στο Toolbox ή να χρησιμοποιήσουμε reflection - extender classes;

Ευχαριστώ
Mike Evans

Είναι λίγο περίεργη η ερώτησή σου... Για ποιόν λόγο, ποιό πρόβλημα θα λύσεις, αν κάνεις inherit κάθε control θέλεις να χρησιμοποιήσεις, εφ' όσον δεν πρόκειται για παράδειγμα να παράγεις ένα νέο με επιπρόσθετα χαρακτηριστικά ή που να αλλάζει την συμπεριφορά του base control;

---

Vir prudens non contra ventum mingit

Για να μπορώ από ένα σημείο να αλλάξω την συμπεριφορά όλων των control. Π.χ. έχω ένα SLE control με Default χρώμα. Κάποια στιγμή θέλω να αλλάξω το χρώμα από όλα τα control αυτού του τύπου σε όλη την εφαρμογή.  Επίσης αργότερα  θέλω να προσθέσω-αλλάξω  δυνατότητες σε κάποια control.

Ευαχαριστώ
Mike Evans

γενικά καλό είναι όλα τα subclasses αυτά των διαφόρων controls να κάνουν implement ένα κοινό interface που θες (π.χ. IColoredControl)

στο θέμα σου τώρα, επειδή απ'ότι καταλαβαίνω σε νοιάζει να κάνεις αλλαγή σε ένα σημείο στο COMPILE-time και όχι δυναμικά στο RUNTIME, μπορείς να βάλεις όλα τα subclasses να καλούν στο constructor τους μια static init method περνώντας τον εαυτό τους σε αυτή ΩΣ το Interface που υλοποιούν

π.χ.
public shared sub GlobalInit(ByRef c As IColoredControl)
...
end sub

kai ston constructor tis klasis sou kalese to GlobalInit(CType(me,IColoredControl))

to CType isos den xreiazetai kan mias kai mporei na ginei implicit type conversion (i klasi sou ilopoiei to interface IColoredControl pou thelei i GlobalInit)

akomi kalitera min exeis xyma shared (static) functions se modules alla valtes se Manager classes pou sigkentronoun aftes tis shared methods

---

Microsoft MVP J# 2004-2010
Borland Spirit of Delphi 2001
http://zoomicon.com

Kάποια απ'αυτά είναι όντως για το compile time. Θα υπάρχουν όμως άλλοι παράμετροι που θα πρέπει να αλλάζουν στο Runtime πχ η μορφή εμφάνισης ημερομηνίας για την οποία θα υπάρχει παράμετρος καταχωρημένη σε αρχείο (MSSQL) για τον τρόπο με τον οποίο θα εμφανίζεται. Σκέφτομαι για αυτές τις παραμέτρους να έχω μία Public Class  με Propertys τις αντίστοιχες runtime παραμέτρους. Κατά την εισαγωγή στο πρόγραμμα θα γίνεται initialize τα propertys και οι subclassed κλάσεις θα χρημοποιούν σαν Init τιμές τις παραμέτρους αυτές. Σκέφτεσται κάτι καλύτερο; Επίσης έχει κάποιος ιδέα γιατί δεν ενεργοποιεί το VS τον designer  σε περίπτωση που κάνουμε Inherit από ένα control πχ button;

Ευχαριστώ
Mike Evans

Δεν μπορώ να καταλάβω γιατί o Designer υποστηρίζεται μόνο από control που προέρχονται από το usercontrol και δεν υποστηρίζεται πχ από αυτά που προέρχονται από πχ το control.

Mike Evans

Γιατί η συνεργασία μετάξυ designer και controls/components βασίζεται σε συγκεκριμένα interfaces. Η κλάση usercontrol σου προσφέρει ακριβώς αυτό, υλοποίηση των interfaces που χρειάζεται ο designer προκειμένου να επιτευχθεί το intergration. Αν ξεκινάς να φτιάξεις ένα δικό σου control από το μηδέν, ήτοι το control class, τότε θα πρέπει να υλοποιήσεις εσύ τον κώδικα του intergration. Αλλά ακόμα κι αν ξεκινήσεις από το usercontrol class, σου παρέχεται ένα βασικό functionality και εσύ θα πρέπει για παράδειγμα να φτιάξεις custom designers, type editors, κλπ.

Όλα αυτά τα ωραία μπορείς να τα βρεις στο βιβλίο του Chris Sells, "Windows Forms Programming in Visual Basic .NET" που προτείνει ο Παναγιώτης. Έχει δύο κεφάλαια για το συγκεκριμένο θέμα, ωστόσο αυτά που αναφέρονται στο κεφάλαιο για το design-time integration τα είχε δημοσιεύσει παλίοτερα στο MSDN Magazine και μπορείς να το βρεις εδώ: http://msdn.microsoft.com/msdnmag/issues/03/04/Design-TimeControls/default.aspx και το δεύτερο μέρος εδώ: http://msdn.microsoft.com/msdnmag/issues/03/05/Design-TimeControls/default.aspx

---

Vir prudens non contra ventum mingit

Πρώτα απ'ολλα να σε ευχαριστήσω για τις απαντήσεις σου και ιδιαίτερα για τα πολύ καλλά Links. Αυτό που μου κάνει εντύπωση είναι ότι αφού παράγω ενα assembly με τα inherited control από άλλο project μπορώ να έχω για αυτά Design time support. Δεν θα μπορούσε αυτόματα το VS να κάνει το ίδιο και κατά την ώρα που φτιάχνω το assembly με τα inherited control;

Ευχαριστώ
Mike Evans

Αν κατάλαβα καλά αυτό που ρωτάς, η απάντηση είναι "όχι" γιατί ουσιαστικά ένα control "τρέχει" από την στιγμή που το τοποθετούμε μέσω του designer πάνω στην φόρμα. Δηλαδή, τα controls έχουν διπλή ζωή... Εκτελείται κώδικας τους κατά το run-time της φόρμας αλλά και κατά το design-time της φόρμας. Όταν για παράδειγμα αλλάζεις το text property ενός button και στον designer βλέπεις τη νέα του τιμή, τότε από πίσω έχει τρέξει κάποιος κώδικας για να συμβεί αυτό...
Άρα λοιπόν, θα πρέπει να έχεις ήδη φτιάξει το control, ώστε μετά να το χρησιμοποιήσεις σε κάποιο άλλο Project...

---

Vir prudens non contra ventum mingit