C++ Ευρεση παραθύρου!

[παπι]

Mig, το t* ειναι το ιδιο χρησιμο με το να χρησιμοποιεις far/near pointer.... ( far LP* near NP*, πχ LPSTR -> far pointer to string, NPSTR -> near pointer to string )

 

Δηλαδη θελω να πω, οτι και υποστηριζουν κατι τα wins, δεν σημαινει οτι ειναι και χρησιμο.

 

Τελος, WCHAR vs CHAR... WCHAR βεβαια. Το αλλο εξαρταται απο τις ρυθμισεις των windows, εαν εχεις δευτερη γλωσσα τα ελ τοτε θα τα δεις, αν οχι, πακετο.

[Directx]

Καλησπερα!

 

Φτιάχνω ένα προγραμματάκι σε C++ το οποιο μεσα απο τη διαδικασια EnumWindows βρίσκει ολα τα ενεργα μή κρυμενα παραθυρα σε περιβάλλον Windows. Μέσα απο αυτή τη διαδικασία θέλω να τσεκάρω εαν ένα συγκεκριμένο παράθυρο ειναι ανοιχτό. Στον παρακάτω κώδικα πως μπορω να ελέγξω αν το παραθυρο είναι ανοιχτο;

BOOL CALLBACK FindTheDesiredWnd(HWND hWnd, LPARAM lParam)
{
	TCHAR title[500];
	TCHAR test[500] = TEXT("WinLister");
        ZeroMemory(title, sizeof(title));
	
	GetWindowText(hWnd, title, sizeof(title) / sizeof(title[0]));
	if (IsWindowVisible(hWnd))
	
	if (lstrcmp(title, "WinLister") == 0)
	{
		wcout << TEXT("Window Found") << std::endl;
	}
	else{
		wcout << TEXT("Can't Find It ") << std::endl;
		}
	return TRUE;
}

int main() {
	EnumWindows(FindTheDesiredWnd, 0);
	cin.get();
	return 0;
}

 

Μπορείς να δεις και την IsIconic, αν είναι TRUE τότε το παράθυρο είναι minimized διαφορετικά (<> TRUE) είναι Restored ή Maximized.

 

 

Δες και τις FindWindow / FindWindowEx

 

Για παράδειγμα:

/*
 * Is Window Open or Minimized?
 *  xdir.
 *
 * compiled with C++ Builder XE.
 */
#include <windows.h>
#include <iostream>
#include <boost\logic\tribool.hpp>

using namespace std;
using namespace boost;

tribool isWindowOpen(const string& Title);

int main(int argc, char **argv) {

	if(argc == 1) {
		cout << " usage: top-level window caption" << endl;
	} else {
		const tribool r = isWindowOpen(argv[1]);

		if(indeterminate(r)) {
			cout << " Window not found : " << argv[1] << endl;
		} else {
			cout << " Window " << (!r ? "not ": "") << "open : " << argv[1] <<endl;
		}
	}

	return 0;
}

// Return true when window is not an icon else false.
// If window not found return BOOST tribool 'indeterminate' value.
boost::tribool isWindowOpen(const string& Title) {
	const HWND hWnd = FindWindow(NULL, Title.c_str());

	return hWnd ? tribool(!IsIconic(hWnd)): tribool(indeterminate);
}

Σημείωση:

Η συνάρτηση isWindowOpen ψάχνει μέσω της FindWindow για το HWND του πρώτου παραθύρου του οποίου ο τίτλος ισούται με Title και επιστρέφει ένα BOOST tribool. Το tribool είναι μια κλάση της βιβλιοθήκης BOOST (σκέψου την σαν μια "έξτρα" STL) η οποία επιτρέπει 3 καταστάσεις σε ένα bool, την true, false και την indeterminate (δηλαδή ούτε true ούτε false). Αν το παράθυρο είναι ανοιχτό (<> IsIconic) η συνάρτηση λοιπόν επιστρέφει true διαφορετικά false. Αν το παράθυρο δεν υπάρχει επιστρέφει την τιμή indeterminate.

 

** Στην αργκό του Windows API, ένα ελαχιστοποιημένο παράθυρο θεωρείται icon καθώς στα 16μπιτα Windows τα ελαχιστοποιημένα παράθυρα εμφανίζονταν ως εικονίδια στο Desktop (καθώς δεν υπήρχε η TaskBar) ενώ το ίδιο το Desktop .. δεν επέτρεπε Shortcuts σε αυτό (παρά μόνο στο παράθυρο του File Manager).

 

Καλή συνέχεια!

 

 

 

Επεξ/σία 12 Ιουνίου 2014 από Directx

[migf1]

Mig, το t* ειναι το ιδιο χρησιμο με το να χρησιμοποιεις far/near pointer.... ( far LP* near NP*, πχ LPSTR -> far pointer to string, NPSTR -> near pointer to string )

 

Δηλαδη θελω να πω, οτι και υποστηριζουν κατι τα wins, δεν σημαινει οτι ειναι και χρησιμο.

 

Τελος, WCHAR vs CHAR... WCHAR βεβαια. Το αλλο εξαρταται απο τις ρυθμισεις των windows, εαν εχεις δευτερη γλωσσα τα ελ τοτε θα τα δεις, αν οχι, πακετο.

 

Καμία σχέση με far/near pointers. Τα t* είναι πολύ χρήσιμα όταν θέλεις χωρίς πολλά-πολλά να στείλεις output στην ανάπηρη κονσόλα των Windows...

#define WIN32_LEAN_AND_MEAN

//#define _UNICODE
//#define UNICODE

#include <windows.h>
#include <tchar.h>

#include <stdio.h>

int main( void )
{
	TCHAR s[] = TEXT("α μπε μπα μπλομ\n");
	_tprintf( TEXT("%s\n"), s );
	return 0;
}

Λάβε υπόψη σου, πως π.χ. η Pelles C δεν υποστηρίζει το flag _O_WTEXT στην _setmode() και πως αν θυμάμαι σωστά ο mingw32 το _fileno() το θέλει fileno(). Με 2 λόγια, με τα t* κάνεις τη δουλειά σου και γρήγορα και παντού.

 

@DirectX:

 

Ωραίος!

 

Μια απορία μόνο, αυτό εδώ:

wcout << TEXT("Window Found") << std::endl;

δουλεύει ανεξαρτήτως _UNICODE/UNICODE? Γιατί εγώ νομίζω πως πρέπει να αντικατασταθεί με _tprintf() αλλιώς χωρίς τα _UNICODE/UNICODE θα βαρέσει o compiler.

 

EDIT:

Ok, μόλις το δοκίμασα με mingw32... δεν βαράει ο compiler (δεν το θυμόμουν πως η wcout κάνει synchronize με την cout), αλλά όπως είναι φυσικό δεν τυπώνει κιόλας αυτό που θέλουμε στην κονσόλα. Με _tprintf() τυπώνει κανονικά.

Επεξ/σία 12 Ιουνίου 2014 από migf1

[migf1]

...

Τελος, WCHAR vs CHAR... WCHAR βεβαια. Το αλλο εξαρταται απο τις ρυθμισεις των windows, εαν εχεις δευτερη γλωσσα τα ελ τοτε θα τα δεις, αν οχι, πακετο.

Μόλις το πρόσεξα αυτό (και βασικά είναι αυτό για το οποίο μίλησα κι εγώ στην 1η σελίδα). Πώς θα στείλεις WCHAR στην κονσόλα; Από όσα γνωρίζω (που δυστυχώς είναι ελάχιστα συγκριτικά με τον και στο win32 api γκουρού defacer) ή θα καλέσεις _setmode(_fileno(stdout), O_[W|U8|U16]TEXT) ή θα το κάνεις με το win32 api console interface.

 

Για την _setmode έγραψα πριν για τα θέματα που προκύπτουν ανάμεσα σε διαφορετικούς compilers.

 

Οπότε μας μένει το win32 api console interface. Μια χαρά εναλλακτική, αλλά έτσι κι αλλιώς πάλι θα χρησιμοποιήσεις κάποιου είδους sprintf() για να βάλεις στο buffer της WriteConsole τις πληροφορίες που θέλεις να τυπώσεις (π.χ. τιμές μεταβλητών).

 

Μια άλλη εναλλακτική που ανά περίπτωση με βολεύει πολύ περισσότερο είναι με τα t*. Κάνω (ή μάλλον έκανα, γιατί τώρα δεν ασχολούμαι με win32 api) τα debug builds σε ANSI και το release build σε Unicode, με μόνη αλλαγή τον ορισμό των UNICODE/_UNICODE directives.

 

Δηλαδή, στο απλουστευμένο παράδειγμα που έδωσα παραπάνω, το debug build θα μπορούσε να ήταν κάπως έτσι...

#define WIN32_LEAN_AND_MEAN

//#define _UNICODE
//#define UNICODE

#include <windows.h>
#include <tchar.h>
#include <stdio.h>

#if !defined(UNICODE) || !defined(_UNICODE)
#define DBGOUT_A	_tprintf
#else
#define DBGOUT_A(...)
#endif

int main( void )
{
	TCHAR s[] = TEXT("α μπε μπα μπλομ\n");
	DBGOUT_A( TEXT("%s\n"), s );
	return 0;
}

και για το release build απλώς θα κάναμε uncomment τα _UNICODE/UNICODE (ή θα τα ορίζαμε στη γραμμή εντολών του compiler).

 

Εσένα π.χ. δεν σε βολεύει έτσι; Κανένα πρόβλημα, δεκτό και κατανοητό. Εμένα ανάλογα με το project, άλλοτε με βολεύει καλύτερα έτσι, άλλοτε όχι. Δεν θα με αναγκάσεις λοιπόν εσύ κουνώντας μου δασκαλίστικα το δάχτυλο ούτε να χρησιμοποιήσω το console interface με το έτσι θέλω, ούτε θα με αναγκάσεις να χρησιμοποιήσω τον compiler που χρησιμοποιείς εσύ για να το κάνω όπως θέλεις εσύ. Αν διαφωνείς με αυτή την προσέγγιση (που btw δεν την έβγαλα από το μυαλό μου) και θέλεις να με μεταπείσεις, εξήγησέ μου όμορφα κι ωραία σαν ενήλικας και γνώστης που είσαι, που και γιατί θεωρείς πως κάνω λάθος, και το συζητάμε (btw, τα 'εσυ' παραπάνω είναι που λέει ο λόγος, δεν αναφέρονται σε σένα προσωπικά).

 

ΥΓ. Τα υπόλοιπα περί σωτήριων ετών, τραγικών, you are doing it wrong, υποστήριξης WinME, κλπ τραγελαφικά είναι για να χαίρονται αναμεταξύ τους παιδάκια στο νηπιαγωγείο.

 

EDIT:

 

Συνήθως είναι όντως έτσι. Εδώ όμως έχει κανένα νόημα πια να μην χρησιμοποιείς UTF-8 ? (στην περίπτωση των windows UTF-16 ή ό,τι χρησιμοποιούν).

 

Θυμάμαι ένα πράγμα που με τσάτιζε στα windows ήταν ότι το notepad έσωζε από τη μάνα του σε iso (σε windows-1253 για την ακρίβεια).

 

Ποιος ο λόγος σήμερα να μην χρησιμοποιείς κάποια αναπαράσταση του unicode ? Στην συγκεκριμένη περίπτωση acked και από εμένα ο αφορισμός. Είτε γράφεις C ή κάποια ιστοσελίδα ή οτιδήποτε και δεν χρησιμοποιείς Unicode, πρέπει να βγαίνει ένα χέρι από το IDE και να σε σφαλιαρίζει

Το βασικό πρόβλημα είναι η κονσόλα των Windows, που από default (και άρα ως stdout/stdin) δεν είναι "γυρισμένη" σε Unicode (ένα άλλο πρόβλημα είναι πως τα Windows χρησιμοποιούν UTF-16 εσωτερικά, αλλά ας μην το μπλέξουμε κι αυτό τώρα). Οπότε, για να γράψεις Unicode στην κονσόλα πρέπει ή να "ταλαιπωρηθείς" με το win32 api console interface (εκτός αν η _setmode() δουλεύει στον compiler σου οπότε χρησιμοποιείς τις παπαδιές που κάνει εκείνη), ή να κάνεις χειροκίνητες παπαδιές, ή να πας... πλαγίως και να χρησιμοποιήσεις τις έτοιμες παπαδιές του tchar.h (με όσα limitations σημαίνει αυτό... δεν κάνει για όλες τις περιπτώσεις).

[παπι]

Χρησιμοποιω dbgPrint (OutputDebugString), και αυτο οταν δεν με βολεβουν breakpoints/watchers.

 

Εαν επρεπε για.... ξερω γω ποιο περιεργο λογο.. να κανω redirect σε console τα debug msgs, τοτε θα εκανα κατι τετοιο

#if _DEBUG
#define PROJECT_CODE_PAGE 737
class dbgstream
	: public std::ofstream
{
public:
	dbgstream() :
		std::ofstream(stdout)
	{}
	friend dbgstream& operator<<(dbgstream& os, const wchar_t* str){
		DWORD dwSize = WideCharToMultiByte(PROJECT_CODE_PAGE,0,str,-1,0,0,0,0);
		char *buf = new char[dwSize];
		WideCharToMultiByte(PROJECT_CODE_PAGE,0,str,-1,buf,dwSize,0,0);
		os<<buf;
		delete []buf;
		return os;
	}
};
dbgstream _dbgout;
#define DEBUG_CTX(x) x
#else
#define DEBUG_CTX(x)
#endif


int main() 
{
	DEBUG_CTX(_dbgout<<L"ΕΛΕΟΣ "<<1<<" "<<1.2<<std::endl);

[migf1]

Ναι, μετατρέπεις χειροκίνητα τα wchar_t σε ANSI πριν τα στείλεις στην κονσόλα. Επειδή είσαι σε C++ εκμεταλλεύεσαι και τα streams, σε C πρέπει να κάνεις sprintf. Κι αν θες να το κάνεις να μοιάζει με την κλάση που δείχνεις, θα πρέπει να φτιάξεις μια αντίστοιχη variadic συνάρτηση για να μπορείς να της περνάς μεταβλητό πλήθος παραμέτρων. Και μέσα της πιθανότατα θα χρειαστεί μετά να καλέσεις την vsprintf (για να χτίσεις το string που θα περάσεις στην WideCharToMultiByte... ή μπορείς να το χτίζεις στον caller και να το περνάς έτοιμο, με ότι + και - συνεπάγεται αυτό στο structure του προγράμματός σου). Αλλά και η vsprintf (και ειδικά η vsnprintf()) έχει ασυμβατότητες μεταξύ των compilers από ότι θυμάμαι.

 

Αυτό που δείχνεις κάπου το έθιξα, σε κάποιο προηγούμενο ποστ αν θυμάμαι καλά (να μετατρέπεις δηλαδή χειροκίνητα από wchar_t σε char προκειμένου να τα στείλεις στην κονσόλα. Είναι κι αυτό μια εναλλακτική).

 

Η ουσία είναι πως και το <tchar.h> είναι ακόμα μια εναλλακτική για το ίδιο πράγμα. Και είναι μια εναλλακτική που έχει πολύ μεγαλύτερο βαθμό συμβατότητας ανάμεσα στους compilers, χωρίς έξτρα steps, περιττούς πονοκεφάλους, κλπ (δεν λέω 100% για να μην είμαι απόλυτος, αλλά εγώ όπου τα έχω δουλέψει δουλεύουν μια χαρά με τη μια... η διαφορά είναι πως εγώ τα έχω δουλέψει με C και όχι με C++)

[defacer]

int main( void )
{
    TCHAR s[] = TEXT("α μπε μπα μπλομ\n");
    DBGOUT_A( TEXT("%s\n"), s );
    return 0;
}

Αν δεν καταλαβαίνουμε όλοι ότι η "λύση" στο "πρόβλημα" ξεκινάει από το TCHAR s[] δεν ξέρω σε τι γλώσσα να το πω για να το καταλάβουμε. Οπότε η ερώτηση για το ένα εκατομμύριο ευρώ είναι: γιατί έχεις εκεί TCHAR in the first place? Επειδή το πρόγραμμά σου χρειάζεται dual build για άλλο λόγο; Ποιός είναι αυτός ο άλλος λόγος; Δε θα μάθουμε ποτέ.

 

Ο μόνος λόγος που θα μπορούσε να υπάρχει είναι ότι το χρειάζεσαι για να μπορείς να κάνεις interoperate με κάτι άλλο που δεν είναι υπό τον έλεγχό σου, κι αυτό ακόμα μόνο στην περίπτωση που το πρόβλημα δε λύνεται γράφοντας κώδικα γιατί προφανώς μια runtime λύση (όταν είναι εφικτή) είναι πολύ καλύτερη από διαφορετικά builds. Τι είναι λοιπόν αυτό το κάτι άλλο με το οποίο δε μπορείς να κάνεις interoperate παρ' εκτός κι αν χρησιμοποιήσεις TCHAR? Δε θα μάθουμε ποτέ.

 

Φυσικά το γεγονός ότι π.χ. το UNICODE είναι switch που ο λόγος ύπαρξής του είναι να αλλάζει τον ορισμό του TCHAR και π.χ. της GetWindowText ταυτόχρονα θα ήταν ίσως ένα hint για να μας πει ότι το TCHAR υπάρχει για να το χρησιμοποιείς με τη GetWindowText και όχι ότι η ύπαρξη και μόνο της GetWindowText δικαιολογεί τη χρήση του TCHAR, αλλά αυτό ισχύει μόνο αν έχεις μυαλό να σκεφτείς.

 

Κλασική περίπτωση βέβαια στα αποστάγματα σοφίας του migf1 όπου το πρώτο 90% της ακυρίλας θεωρείται untouchable γιατί το λέω εγώ και πατώντας πάνω στην untouchable ακυρίλα "δικαιολογείται" και το 10% της κορυφής του παγοβούνου.

 

Ορίστε και μερικές απόψεις τρίτων έτσι για το γαμώτο: http://stackoverflow.com/questions/234365/is-tchar-still-relevant

 

Επίσης http://stackoverflow.com/questions/6315566/should-i-eliminate-tchar-from-windows-code

 

should I eliminate TCHAR from Windows code?

 

Yes, you should. The reason TCHAR exists is to support both Unicode and non-Unicode versions of Windows. Non-Unicode support may have been a major concern back in 2001 when Windows 98 was still popular, but not today. And it's highly unlikely that any non-Windows-specific library would have the same kind of char/wchar_t overloading that makes TCHAR usable.

So go ahead and replace all your TCHARs with wchar_ts.

 

Bonus stage αυτά που λέει στο ίδιο το MSDN:

 

New applications should always call the Unicode versions (of the API).

The TEXT and TCHAR macros are less useful today, because all applications should use Unicode.

 

Έχουμε πήξει στη γνώση σ' αυτό το forum. migf1 πες τους κι αυτούς ότι είναι στείρες υπεραπλουστεύσεις αυτά που λένε, ο κάθε νέος developer θα έπρεπε να είναι ελεύθερος να κάνει τα πράγματα με λάθος τρόπο επειδή εσύ ποτέ δεν έμαθες το σωστό.

[migf1]

Καλώς τον γκουρού. Αν μετά από 2 σελίδες ακόμα δεν έχεις καταλάβει περί τίνος πρόκειται, "τότε λυπάμαι αλλά θα πρέπει να μάθεις την απάντηση από αλλού. Στη συγκεκριμένη περίπτωση εγώ βαριέμαι να λέω αυτονόητα".

 

Επίσης (όχι ότι θα καταλάβεις τώρα, αλλά γενικώς δεν ποστάρω για σένα):

MSDN (το έχει δώσει ο γκουρού το λινκ):

...

The TEXT and TCHAR macros are less useful today, because all applications should use Unicode. However, you might see them in older code and in some of the MSDN code examples.

...

[defacer]

Σαφώς και έχω καταλάβει περι τίνος πρόκειται. Χρόνια τώρα.

 

Όσον αφορά το θέμα μας, νομίζω ότι η εμπεριστατωμένη σου απάντηση τα λέει όλα καλύτερα απ' όσο θα μπορούσα να τα πω εγώ.

[migf1]

@defacer:

 

Σου το είπα και πριν, αφού είσαι άσχετος από Win32 API γιατί συνεχίζεις να προκαλείς και να εκτίθεσαι; Ο παπι μέσα σε 2 ποστς και μπήκε αμέσως στο νόημα και πόσταρε εναλλακτικό κώδικα. Εσύ συνεχίζεις τον χαβά σου (συνέχισε μόνος σου).

 

@forum:

 

Όσοι θέλετε να ασχοληθείτε με Win32 API Programming, ένα πολύ καλό και αρκετά σύγχρονο (καλύπτει μέχρι και Win7) βιβλίο κατά την άποψή μου είναι το Windows System Programming, του Τζόνσον Χαρτ. Το 2010 βγήκε η 4η έκδοση.

 

Τον θυμήθηκα με αφορμή τον εγχώριο... γκουρού που μεταξύ άλλων ωραίων του αρέσει να επικαλείται και 3ους (οι 3οι είναι το stackoverflow και η wikipedia), κι επειδή τυγχάνει να το έχω το βιβλίο αυτό, παραθέτω ένα μικρό απόσπασμα (θα το γράψω με το χέρι, τι να κάνω... γκουρού είναι αυτός)...

 

Chapter 2: Using the Windows File System & Character I/O

...

Interlude: Unicode and Generic Characters

...

Windows uses Unicode 16-bit characters throughout, and NTFS file names and pathnames are represented internally in Unicode. If the macro is defined, wide character strings are required by Windows calls; otherwise, 8-bit character strings are converted to wide characters. Some Windows API functions only support Unicode, and this policy is expected to continue with new functions.

 

All future program examples will use instead of the normal for characters and character strings unless there is a clear reason to deal with individual 8-bit characters. Similarly, the type indicates a pointer to a generic string, and indicates, in addition, a constant string.

 

At times, this choice will add some clutter to the programs, but it is the only choice that allows the flexibility necessary to develop and test applications in either Unicode or 8-bit character form so that the program can be easily converted to Unicode at a later date. Furthermore, this choice is consistent with common, if not universal, industry practice.

...

Πιο κάτω, αναφέρει την ολοένα και αυξανόμενη τάση για αποκλειστική χρήση Unicode ειδικά στα GUI...

Unicode Strategies

...

As mentioned previously, writing generic code, while requiring extra effort and creating awkward-looking code, allows the programmer to maintain maximum flexibility. However, Unicode only (Strategy 3) is increasingly common, especially with applications requiring a graphical user interface.

Κάτι που φυσικά είναι τελείως διαφορετικό από το παραλήρημα (και μάλιστα άνευ πρόκλησης) του... γκουρού στην 1η σελίδα του νήματος.

 

Και συνεχίζει, δίνοντας μια ρουτίνα για errors, γραμμένη με t* φυσικά (δεν είναι μεγάλη, αλλά έχουμε κι άλλες δουλειές να κάνουμε)

 

Στο δια ταύτα, κάντε... connect τα dots μεταξύ των αναγραφόμενων του Χαρτ και του τρόπου που περιέγραψα ως θεμιτή εναλλακτική για γρήγορο debugging με χρήση του tchar.t και βγάλτε τα συμπεράσματά σας.

 

Ακόμα καλύτερα, αν φυσικά αποτελεί τομέα που σας ενδιαφέρει (εμένα όχι πια) πάρτε το βιβλίο (όχι, δεν έχω καμία σχέση ούτε με τον συγγραφέα ούτε με τον εκδοτικό του οίκο ).

 

EDIT:

 

Btw, ανάλογα το project (βασικά πολλές φορές) δεν χρειάζεστε καν τα LPCSTR/LPSTR... μπορείτε να χρησιμοποιήσετε απευθείας TCHAR, TCHAR * και const TCHAR *.

 

Over and out...

[defacer]

Ήμουν σίγουρος ότι θα έψαχνες απεγνωσμένα να βρεις να ποστάρεις κάτι τέτοιο.

 

Λοιπόν ο Hart πολύ σωστά εξηγεί τι κερδίζεις μπαίνοντας σ' αυτό τον κόπο. Αυτό που δεν εξηγεί (τουλάχιστον στο απόσπασμα που πόσταρες) είναι το γιατί να σ' ενδιαφέρει να το κερδίσεις. Απάντηση: δε σ' ενδιαφέρει, εκτός αν φτιάχνεις προγράμματα για Windows 98 ή Windows CE.

 

Και industry practice δεν είναι το να γράφεις με TCHAR τελεία. Είναι το να γράφεις με TCHAR όταν θέλεις να έχεις την παραπάνω δυνατότητα. Την οποία... άσε, τον αράπη κι αν τον πλένεις. Και φυσικά δε μπαίνεις στον κόπο να μας πεις γιατί το "Unicode only" είναι "increasingly common" αν το άλλο είναι προτιμότερο.

 

Αλλά άσε, ας μας πει ο ίδιος ο Hart:
 

A programmer starting a Windows project, either to develop new code or to enhance or port existing code, can select from four strategies, based on project requirements.

 

Λοιπόν επαναλαμβάνω την προηγούμενη ερώτησή μου: ποιά είναι αυτά τα requirements που έχεις και σε αναγκάζουν να χρησιμοποιήσεις TCHAR? Γιατί η χρήση του δεν είναι "δωρεάν", άλλωστε ο ίδιος έγραψες ότι "while requiring extra effort and creating awkward-looking code"... άρα κάτι περιμένεις να βγάλεις από αυτό το extra effort.

 

Τι περιμένεις να βγάλεις; Ποτέ δε θα μάθουμε.

 

Φανερά η λάθος ερμηνεία των όσων λέει η αυθεντία Hart είναι καλύτερη από τη σωστή ερμηνεία όσων λένε όλοι οι άλλοι developers που δεν έχουν γράψει βιβλίο.

 

ΥΓ: Το StackOverflow και τη Wikipedia τα απαξιώνεις μαεστρικά -- λογικό, αφού σε αντίθεση με το insomnia όπου γράφουν μόνο γκουρού εκεί πάει και γράφει ο κάθε άσχετος. Το MSDN? Τουμπεκί;

[migf1]

Εσύ όλο σίγουρος είσαι για όλα και για τα πάντα, γκουρού με τα όλα του... εγώ πάπαλα πάντως (for good this time).

[defacer]

Στην απίθανη περίπτωση πάντως που ξαναβρεις τη μιλιά σου ποτέ και θυμηθείς τι ρώτησα, ξέρεις εδώ είμαστε.

[H_ANARXIA_EINAI_PSEMA]

defacer βρες γκόμενα

[georgemarios]

<JokingMoodOn>

Ελεγα πως οποιος ξεκινα καινουργια εφαρμογη (για PC) που δεν ειναι Unicode επρεπε να πυροβολειται.

Διαβαζοντας το thread σκεφτομαι πως θα πνιγομασταν απο το αιμα.

</JokingMoodOn>