Newsgroup: it.comp.programmare.win32
Titolo: [VC++ API] Edit READONLY ma non disabled

Salve a tutti,
ho una domanda per i più esperti di controlli Edit..
Vorrei creare un EditBox multiline non modificabile,
ma non "ingrigito" come con lo stile ES_READONLY!
In oltre,  cosa ancora più gradita, sarebbe dare la
possibilita' all'utente di selezionare il testo, pur
non potendo modificarlo.
Grazie a chiunque mi sappia indirizzare nella 
giusta direzione...
Ph.

, 
Phon...@hotmail.com
 says...

Lo crei con lo stile ES_READONLY e poi gli cambi colore intercettando il 
WM_CTLCOLORSTATIC. Oppure (piu' complesso) lo subclassi e annulli gli 
effetti dell'inserimento del testo.
Luca

 effetti dell'inserimento del testo.
A mio giudizio č molto meglio il tuo secondo consiglio (derivare una classe
da CEdit), in ogni caso il fatto di "annullare gli effetti dell'inserimento
del testo" lo potevi chiarire un po' meglio...
Se non ti č chiaro Phones, chiedi pure...
ma ciao

 Se non ti è chiaro Phones, chiedi pure...
Mmm dunque dunque.. innanzi tutto grazie a tutti e due!!
Premetto che NON uso MFC.
Per quanto riguarda il disegno, non mi e' mai piaciuto usare i pennelli
sulle finestre:
a parte ciò...
WM_CTLCOLORSTATIC
hdcStatic = (HDC) wParam; // handle to display context
hwndStatic = (HWND) lParam; // handle to static control
Ditemi se sbaglio:
ho l' HDC, mi serve il pennello, quindi:
hbrush = CreateSolidBrush(RGB(255, 255, 255));
(e dopo
DeleteObject(hbrush);
)
Ora come faccio a spalmare il mio brush su tutta la editbox (ovviamente non
comprendendo i margini e la scrollbar)?
__
Per quanto invece riguarda il window subclassing (che mi sembra
interessante)
dovrei:
Crearmi una fake EditProc ed impostarla con SetWindowLong(); questa
EditProc, dovrebbe
inviare tutti i messaggi alla true WndProc (quella interna a Windows),
tranne quelli che indicano all'editbox che c'è stato l'imput dall'utente!
MMm ovvero?
WM_CHAR, WM_CLEAR, WM_CUT
Dubbio: ma in questo modo, il mio stesso programma sarà in grado di
modificare il testo?!
Io voglio inibire la modifica SOLO all'utente!!
Ph.
--------------------------------
Inviato via 
http://usenet.libero.it


Si, la SetText e simili  non sono influenzate.
Ciao.
Luca


 Nemmeno io :)
Io sempre...
Ma mi spiegate questa antipatia per MFC? Tutto sommato è un'insieme di
classi che fanno da "wrapper" alle API standard, non riesco proprio a capire
le persone che "amano la programmazione con le API" e odiano MFC...deduco
soltanto che a queste persone non piaccia lo re (leggi C++).

 ha scritto nel messaggio
news:P29y9.122655$%M1.31...@twister2.libero.it...

Io non idio le MFC. Non le uso e basta. Non le uso per una serie di motivi:
non programmo in C++, ma in C, in quanto non mi occorrono tutte le
estensioni aggiunte a questo linguaggio (che appesantiscono -anche se poco-
l'eseguibile, e non lo dico solo io). Inoltre i programmi che scrivo io non
sono enormi e in questo caso preferisco interfacciarmi direttamente alla
API, le MFC sarebbero solo un ulteriore strato software fondamentalmente
inutile e non apporterebbero benefici visibili. Sono anche convinto che se
un programma e' ben progettato e la sua architettutra ben definita fin
dall'inizio si puo' dare un'impronta OO anche usando il solo C (ok ok, tutti
i guru della OOP sono pregati di rimettere le mazze con i chiodi al loro
posto, grazie). Mi affascina invece abbastanza la WTL, solo che non conosco
a fondo il C++ e nemmeno ATL, ma chissa' che in futuro... Per ora mi basta
il C pure & simple.
Luca

 il C pure & simple.
Tradotto la "colpa" va cercata più in basso quindi, mi stai incriminando "lo
re"... : )


No, beh, non fraintendiamo... La palla al piede e' data dalle MFC (che tra
l'altro si tirano dietro una bella DLL da 1 mega). Se veramente c'e' un
miglioramento (e io per ora non l'ho visto, almeno in programmi di piccole o
medie dimensioni) l'overhead introdotto puo' essere accettato, altrimenti
no, almeno dal mio punto di vista. Preferisco scrivere 10 righe di codice in
piu' per avere le scritte colorate in una ListView, ma avere un programma
piu' snello.
Luca

 piu' snello.
Non sono molto d'accordo sullo snello (che di solito interpreto come
facilmente modificabile...), anzi su questo la penso proprio nel modo
opposto...

 == (HWND) lParam).
(Dopo 3 tentativi su usenet.IOL provo da google!)
Seguendo i tuoi consigli io ho fatto cosi':
case WM_CTLCOLORSTATIC:
	if (EBox == (HWND) lParam)
		{
		SetDCBrushColor((HDC) wParam,GetStockObject(WHITE_BRUSH));
			return 0;
		}
Peccato che il linker mi dia errore:
main.obj : error LNK2001: unresolved external symbol _SetDCBrushColor
Debug/TFE.exe : fatal error LNK1120: 1 unresolved externals
ma gdi32.lib la linka di default!!!
Perke non funziona??

 
Mi sembra strano l'errore che ti da, dovrebbe darti errore sul secondo 
parametro della SetDCBrushColor che e' un COLORREF (quindi lo ottieni 
con la macro RGB(r, g, b)). Comunque deve diventare cosi':
case WM_CTLCOLORSTATIC:
  if (hEBox == (HWND)lParam)
  {
    return (GetStockObject(WHITE_BRUSH);
  }
  return NULL;
Ciao.
Luca

 ma gdi32.lib la linka di default!!!
quella funzione è presente solo in win2000 e xp, te che OS hai?
Pela

 Pela
win2k!!


 _SetDCBrushColor [...]
  ^^^^^^^^^^^^^^^^
il simbolo è sbagliato, dovrebbe essere _SetDCBrushColor@8 - l'ha 
decorato come __cdecl anzichè __stdcall, e questo significa una sola 
cosa: l'header non la sta definendo. Sospetto che la macro _WIN32_WINNT 
non sia definita appropriatamente:
(wingdi.h)
#if (_WIN32_WINNT >= 0x0500)
WINGDIAPI COLORREF WINAPI SetDCBrushColor(IN HDC, IN COLORREF);
WINGDIAPI COLORREF WINAPI SetDCPenColor(IN HDC, IN COLORREF);
#endif
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.20. C, C++ and ASM developers
                              and beta testers are welcome!