Win32 API + C + UpDown controls

[migf1]

Τελικά δεν πρέπει να χρειάζεται.

 

Σύμφωνα με το MSDN: http://msdn.microsoft.com/en-us/library/ms632682%28v=vs.85%29.aspx εφόσον το tooltip δημιουργείται με parent το dialog, καταστρέφεται μαζί με το Dialog όταν καλούμε EndDialog() ... μαζί με τα υπόλοιπα children του Dialog.

[migf1]

Έχει κανείς άλλος την απορία γιατί τα strings στο Win32 API σημειολογικά ορίζονται ως δείκτες σε strings αντί για δείκτες σε char όπως είναι το σωστό ;

 

Για παράδειγμα, το PSTR ορίζεται ως char* Σημειολογικά θα έπρεπε να είναι κάτι σαν PCHAR. Και το ίδιο συμβαίνει για όλα τα custom typedefs του API.

 

Δεν μπορώ να το συνηθίσω με τίποτα, με μπερδεύει συνέχεια όταν διαβάζω την τεκμηρίωση, γιατί με το που τα βλέπω το μυαλό μου πάει απευθείας από μόνο του σε char **, wchar **, TCHAR **, κλπ. Είναι ασφαλές να υποθέσω πως ισχύει για όλο το API αυτή η σημειολογία και πως δεν πρόκειται ποτέ ένας τύπος που ξεκινάει με P ή LP να αναφέρεται όντως σε πίνακα από strings;

 

Προς το παρόν πάντως τα αποφεύγω τελείως αυτά τα types και χρησιμοποιώ απευθείας μόνο TCHAR, TCHAR * και TCHAR **. Καλώς πράττω; Υπάρχει κάποιος λόγος που τα έχουν έτσι τα custom types στο API;

[nilosgr]

χωρις να ειμαι γκουρου στο WIN32 API, εχω την εντυπωση πως ειναι για λογους συντομιας, οπως τα μακρο _T() και TEXT(), που ειναι ταυτοσημα

[παπι]

χωρις να ειμαι γκουρου στο WIN32 API, εχω την εντυπωση πως ειναι για λογους συντομιας, οπως τα μακρο _T() και TEXT(), που ειναι ταυτοσημα

 

Εννοει γιατι εχει typedef PSTR και οχι PCHAR εφοσον αναφερεται (το typedef) σε pointer to char και οχι σε pointer to pointer to char

[migf1]

Εννοει γιατι εχει typedef PSTR και οχι PCHAR εφοσον αναφερεται (το typedef) σε pointer to char και οχι σε pointer to pointer to char

 

Ακριβώς!

 

Και το ρωτάω στο φόρουμ για να σιγουρέψω πως δεν πρόκειται να με "δαγκώσει" αν το αγνοήσω.

[nilosgr]

Στο WinNT.h (line 421):

>typedef __nullterminated CHAR *NPSTR, *LPSTR, *PSTR;

[migf1]

Ναι, τα έχω δει κι εγώ φίλε nilosgr. Απλά ρώτησα αν υπάρχει κάποιος ιδιαίτερος λόγος που έχουν οριστεί έτσι, που αν δεν ακολουθηθεί μπορεί να ενέχει κινδύνους σε αναβαθμίσεις ή σε ρουτίνες που δεν έχω συναντήσει ακόμα. Btw, διάβασα πως τα LP έχουν καταργηθεί στη πράξη, γιατί αποτελούν απομεινάρια από το 16-μπιτο λειτουργικό.

[παπι]

Οχι. Κανενα προβλημα. Απλα τα εχει ετσι για να ειναι περιγραφικα. Αν δεν τα ειχε, τοτε τους μονους τυπους που θα ηθελες ειναι το void*, int και w/char

[migf1]

Οχι. Κανενα προβλημα. Απλα τα εχει ετσι για να ειναι περιγραφικα. Αν δεν τα ειχε, τοτε τους μονους τυπους που θα ηθελες ειναι το void*, int και w/char

 

Ωραία, thanks!

 

Είδα πως σε άλλα types η σημειολογία του API είναι σωστή. Για παράδειγμα, τα LPRECT/PRECT είναι όντως RECT *. Οπότε υποθέτω πως η δυσαρμονία αφορά μονάχα τα strings.

 

Για κάποιον περίεργο (μαζοχιστικό) λόγο έχει αρχίσει και μου αρέσει, παρόλο που παιδεύομαι πολύ γιατί συν ότι δεν θυμόμουν σχεδόν τίποτα, έχουν προστεθεί και πολλά καινούρια πράγματα στο API. Επίσης, ο migw32 gcc που χρησιμοποιώ ως βασικό compiler (με συμπληρωματικό τον Pelles-C, κυρίως για debugging) έχει αρκετές ελλείψεις στα header files του, οπότε αναγκάζομαι και το προσθέτω από τα header files της Pelles-C (αν και υπάρχει θέμα και με το windres, o resource compiler του mingw, όπου εκεί δεν μπορώ να επέμβω).

 

Είναι αυτό που λένε "πονάω αλλά μου αρέσει" Προφανώς παίζει ρόλο πως ασχολούμαι περιστασιακά χωρίς καμία πίεση χρόνου ή δέσμευση.

 

Βασικά προσπαθώ να φτιάξω ένα Win32 front-end για ένα animal library που είχα ξεκινήσει πριν λίγο καιρό σε στάνταρ C (και που ακόμα δεν έχει τελειώσει). Αρχικά είχα σκεφτεί να κάνω το front-end σε GTK+, αλλά αφενός ξενέρωσα επειδή για Windows το έχουν ακόμα στην έκδοση 2.24 (ενώ κανονικά έχει φτάσει στην 3.2 νομίζω) κι αφετέρου σκέφτηκα πως δεν θα μου έκανε κακό να φρεσκάρω το Win32 API.

 

Βέβαια στην πορεία περισσότερο για εκμάθηση σχεδόν από το 0 εξελίσσεται (άντε από το 1 ή το 2, βαριά-βαριά το 3) παρά για... φρεσκάρισμα.

 

Παρόλα αυτά έχω "κολλήσει" ... σαν να με τραβάει ένας σατανικός μαγνήτης ένα πράγμα

 

Πάντως είναι όντως πακέτο, κυρίως γιατί είναι άναρχα δομημένο το API καθώς επίσης και τεράστιο!

 

Μέχρι στιγμής βρίσκομαι εδώ...

 

 

 

 

όπου λειτουργεί μονάχα το κεντρικό παράθυρο (με κλικ παίζει φωνή του ζώου κάτω από το ποντίκι) και τα spin-buttons του TA Data File dialog. Και μόνο για να φτιάξω αυτό το Dialog λειτουργικό δεν θα φάω και κάνα μήνα με τους ρυθμούς που πάω;

 

ΥΓ1. Διάβαζα χτες για το globalization σε Windows... χάνει η μάνα το παιδί και το παιδί τη μάνα. Από ότι κατάλαβα η όλη ιστορία είναι η κάθε γλώσσα να αποτελείται από ένα ξεχωριστό resource dll, το οποίο αντικαθιστά τη στάνταρ γλώσσα, μέσα στο εκτελέσιμο αρχείο με κάτι (μάλλον πολύπλοκες) συναρτήσεις που υπάρχουν στο API. Ανάλογα δηλαδή τη γλώσσα που θα σου επιλέξει ο χρήστης μέσα στο πρόγραμμα, φορτώνεις το αντίστοιχο .dll στο τέλος του εκτελέσιμου αρχείου στη μνήμη ... ή κάτι τέτοιο. Τέσπα έχω καιρό μέχρι να φτάσω εκεί.

 

ΥΓ2. Γενικώς σε πολλά σημεία θέλει τρελή δουλειά ακόμα και για πράγματα που φαντάζουν απλά στον χρήστη. Π.χ. το να βάλεις εικονίδια δίπλα στα μενού είδα πως δεν υποστηρίζεται απευθείας από το API... πρέπει να κάνεις own-draw τα entries του μενού.

[παπι]

Για τους headers, το καλυτερο ειναι να κατεβασεις το window sdk να εχεις το κεφαλι σου ησυχο.

Επισης δες το windowsx.h που εχει παρα πολλα macro για messages

[migf1]

...

>

#pragma once

#include <windows.h>
#include <CommCtrl.h>
#include <WindowsX.h>
#pragma comment(lib,"ComCtl32.Lib")

#pragma comment(linker,"\"/manifestdependency:type                  = 'win32' \
                                             name                  = 'Microsoft.Windows.Common-Controls' \
                                             version   			= '6.0.0.0' \
                                             processorArchitecture = '*' \
                                             publicKeyToken        = '6595b64144ccf1df' \
                                             language              = '*'\"")
						  				

 

 

Το τελευταιο εχει να κανει με το initcommonctrlex, εγω δεν το καλω, αλλα φτιαχνω ενα embeded manifest για τα commctl v6, ψαξε πως το κανεις αυτο για τον compiler που εχεις

 

Το είχα ξεχάσει αυτό, βρήκα ένα link που περιγράφει πολύ απλά πως να χρησιμοποιείς manifests και visual styles με mingw-32: http://www.transmiss...pps-with-mingw/

 

Το ποστάρω γιατί θεωρώ πως είναι χρήσιμο (έχει και 2-3 ακόμα χρήσιμα άρθρα εκεί). Με 2 λόγια, το manifest το έκανα απλό αρχείο στο ίδιο directory με το .exe, γιατί ο resource editor της Pelles-C δεν δέχεται το RT_MANIFEST keyword στο resource script (το μετατρέπει σε σκέτο MANIFEST). Οπότε αντί να το αλλάζω χειροκίνητα κάθε φορά, το έκανα ξεχωριστό αρχείο με το όνομα του exe.manifest, όπως προτείνει το άρθρο.

 

Δείχνει και τη χρήση της InitCommonControlsEx() η οποία με το bitflag C_WIN95_CLASSES φορτώνει μια πληθώρα από controls Btw, η σχετική γραμμή του κώδικα στο άρθρο είναι λάθος, αντί για...

 

>
icc.dwICC = ICGetModuleHandle(NULL)C_WIN95_CLASSES;

θέλει

>
icc.dwICC = C_WIN95_CLASSES;

Πιο κάτω το έχει σωστά.

 

EDIT:

 

Για τους headers, το καλυτερο ειναι να κατεβασεις το window sdk να εχεις το κεφαλι σου ησυχο.

Επισης δες το windowsx.h που εχει παρα πολλα macro για messages

 

Thanks! Το έχω δει το windowsx.h όταν έψαχνα για τα Message Crackers macros (που τα θυμόμουν από παλιά ). Βέβαια δεν τα χρησιμοποιώ τώρα, βάζω απευθείας δικές μου συναρτήσεις, με ανομοιογενή λίστα παραμέτρων.

 

Π.χ...

 

>
WndMain_OnCreate()
WndMain_OnPaint()
WndMain_OnMouseDown()
κλπ

 

Πάντως γίνεται χαμός ρε συ, μιλάμε για κανονικό ωκεανό!

[nilosgr]

Visual Studio γιατι δεν δοκιμαζεις...;

Εγω (ωντας αρχαριος και σε Win32 και σε C) αντιμετοπιζα προβληματα με το πως θα εκανα linking τα headers του windows SDK, με το Pelles-C και (πριν κανα χρονο) κατελειξα στο Visual Studio κι απο τοτε το λατρεψα!!

[migf1]

Visual Studio γιατι δεν δοκιμαζεις...;

Εγω (ωντας αρχαριος και σε Win32 και σε C) αντιμετοπιζα προβληματα με το πως θα εκανα linking τα headers του windows SDK, με το Pelles-C και (πριν κανα χρονο) κατελειξα στο Visual Studio κι απο τοτε το λατρεψα!!

 

Το δοκιμάζω κατά καιρούς, και πάντα το κάνω uninstal μετά από κάνα 2-ωρο. Με χαλάει πολύ όλος ο "συρφετός" που κουβαλάει η εγκατάστασή του (π.χ. η σώνει και καλά εγκατάσταση του MySQL server της MS μου χαλάει το xampp). Πάντως όποιος θέλει να κάνει σοβαρό Windows Programming (εννοώ μεσαιο-μεγάλα projects) αποτελεί μονόδρομο το VS.

 

Σε ότι αφορά την Pelles-C, προσωπικά δεν θυμάμαι να έχω αντιμετωπίσει προβλήματα. Πρωτο-ξεκίνησα να τη χρησιμοποιώ από την έκδοση 3 αν θυμάμαι καλά (πρέπει να ήταν γύρω στο 2000). Είχα κάνει αρκετές Windows εφαρμογές τότε και δεν είχα πρόβλημα. Μήπως δεν χρησιμοποιούσες τους εξειδικευμένους wizards που έχει για Win .exe/.dll. Χωρίς αυτούς θα πρέπει να προσθέσεις χειροκίνητα στον linker τις βιβλιοθήκες των Windows (και τα folders τους).

 

ΥΓ. @παπι (ή όποιος άλλος): παλιά το windowsx.h συνοδευόταν από ένα "windowsx.txt" το οποίο τεκμηρίωνε λεπτομερώς τα περιεχόμενα του "winodwsx.h". Δεν μπορώ να το βρω πουθενά όμως, μήπως έχει καταργηθεί; Αν το έχει κανείς, θα μπορούσε να το ποστάρει;

[migf1]

Παιδιά συνήθως που αρχικοποιείτε user-defined data ; Στην WinMain(); στην WndProc(); κάπου αλλού. Και επίσης πως τα περνάτε στις διάφορες συναρτήσεις, με τα extra-bytes της WNDCLASS; με WindSetLongPtr(); τα έχετε global; τα περνάτε ως παραμέτρους σε συναρτήσεις; ποια είναι η ενδεδειγμένη πρακτική;

 

Μόλις ανακάλυψα τις SetProp()/GetProp() και ενθουσιάστηκα! Μήπως έχουν κάνα draw-back; Αποτελούν κοινή πρακτική;

[παπι]

Εγω προσωπικα φτιαχνω ενα struct και τον κουμπωνω στο setwindowlong οταν εχω να κανω με καποιο control dialog αν ειναι το main τοτε τα βαζω απλα global.

 

Για να περασω καποια δεδομενα σε καποιο dialog ή control κατα την δημιουργια, τοτε μεσου createWindow/CreateDialog τα βαζω στο lParam και τα παιρνω απο το wm_create/wm_initdialog