Newsgroup: it.comp.programmare.win32
Titolo: OPENFILENAME:"Runtime error, stack overflow"

Mistero!! (Per me.)
Per quale motivo questa "cosa" che ha funzionato fino a pochi giorni
addietro ora mi inchioda la app.
Se seleziono il file con il mouse e premo ok funziona, se muovo la finestra
dialogo (openfile...) va in crash,
se prendo il file con doppio click idem, (anche senza farci nulla con il
file, come nelle righe seguneti*. )
Ho provato anche a disabilitare tutti i vari case WM_LBUTTONUP ,
WM_MOUSEMOVE ec.
Mi succede indipendentemente dalla posizione (nell'app.) dove le metto.
ho provato a escludere le varie parti (righe) ma ottengo sempre:
"Runtime error, stack overflow"      (con il doppio click e muovendo la
finestrella)
Il codice è preso dalla guida in linea e prima funzionava, ovviamente il
problema non è lì anche se collegato.
Cosa accidenti può essere???
Grazie 1000 per ogni spunto.
Fulvio.
P.s Le righe maledette:
{
OPENFILENAME ofn;
char szDirName[255];
strcpy(szDirName, directory_def);
char szFile[255], szFileTitle[255];
UINT i, cbString;
char chReplace; // string separator for szFilter
char szFilter[255];
szFile[0] = '\0';
if ((cbString = LoadString(hinst, IDS_FILTERSTRING, szFilter,
sizeof(szFilter))) == 0)
{ ErrorH(); return 0L; }
chReplace = szFilter[cbString - 1]; // retrieve wildcard
for (i = 0; szFilter[i] != '\0'; i++) { if (szFilter[i] == chReplace)
szFilter[i] = '\0'; }
// Set all structure members to zero.
memset(&ofn, 0, sizeof(OPENFILENAME));
ofn.lStructSize = sizeof(OPENFILENAME);
ofn.hwndOwner = hwnd;
ofn.lpstrFilter = szFilter;
ofn.nFilterIndex = 1;
ofn.lpstrFile= szFile;
ofn.nMaxFile = sizeof(szFile);
ofn.lpstrFileTitle = szFileTitle;
ofn.nMaxFileTitle = sizeof(szFileTitle);
ofn.lpstrInitialDir = szDirName;
ofn.Flags = OFN_SHOWHELP | OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST;
// GetOpenFileName(&ofn))
}

Ci credo che vai in stack overflow, non e` una risorsa
illimitata...
Prova ad allocare un po' di roba tramite new e ad aumentare
la dimensione dello stack (vedi gli help del tuo compilatore alla
voce stack).
Paolo
-----------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
-----------------------------------------------

char szFilter[255];
PREMESSA: queste considerazioni sullo stack sono frutto per gran parte di
immaginazione, non ho certezze!!
La memoria per contenere queste variabili e' lo stack, di cui tu in questo
modo utilizzi piu' di 1KB (255*4 + altro). In genere, non credo sia
possibile sapere di quanto stack tu possa disporre nel momento in cui
"entri" in una funzione (o forse si', magari in assembly con i registri ebp,
esp, qualcuno mi corregga...), dal momento che la cosa dipende da "quando"
tu chiami la funzione.
Cerco di chiarire: al momento della compilazione (o meglio, del linking) del
tuo programma, il linker scrive sul tuo file .exe quanto spazio dovra'
essere allocato per lo stack al momento dell'esecuzione del tuo programma.
Supponiamo che sia 2KB. Quando fai partire il tuo programma, windows assegna
2KB di memoria per lo stack; ogni qualvolta una funzione viene eseguita (o
meglio, non appena viene chiamata), la funzione utilizza tot byte dello
stack per memorizzare, temporaneamente, le sue variabili. Supponiamo ora che
questa funzione (funzione1) chiami un'altra funzione, funzione2. Funzione2
"mette" le sue variabili nello stack, di fianco a quelle di funzione1.
All'uscita, funzione2 "toglie" (in pratica modifica il registro della cpu
che punta alla posizione in memoria dello stack) le sue variabili dallo
stack, liberando lo spazio utilizzato.
Tuttavia, se funzione2 chiama funzione3 che chiama ecc ecc fino a funzione20
potrebbero sorgere dei problemi, ossia la memoria dello stack e' tutta
occupata.
Questo spiega anche perche' non e' necessario che tu abbia modificato la tua
funzione per non farla piu' funzionare: forse hai aggiunto qualche funzione
nella sequenza (pensa all'esempio di prima), oppure semplicemente in una
funzione che la richiama hai dichiarato qualche altra variabile, occupando
altro spazio...
La soluzione?
1) Modifica le dimensioni dello stack nel linker, dovrebbe esserci qualcosa
tra i menu;
2) Invece di quelle stringhe
char nome[255];
dichiari
char* nome;
E fai un bel LocalAlloc(parametri, specificando 255 come size);
nome = (char*)LocalLock(ecc ecc);
Volendo puoi chiamare un LocalAlloc() richiedendo direttamente 1KB (invece
delle quattro chiamate da 255), e sarebbe meglio, se poi sai come gestire i
puntatori.
Saluti,
    Mardy

Innanzi tutto grazie per il tempo che mi dedichi...
Anche questa volta sei stato determinante. Ho cercato sulla guida in linea
(tante prove e non avevo fatto la cosa più semplice :-(  ), ho trovato solo
questo:
///
STACKSIZE Module-Definition Statement STACKSIZE bytes
The STACKSIZE statement specifies the number of bytes needed by the
application for its local stack. An application uses the local stack
whenever it makes function calls.
Parameter Description
bytes Specifies the stack size, in bytes. If the application makes no
function calls, the default stack size is zero. If your application does
make function calls and you specify a stack size smaller than 5K, Windows
automatically sets the size to 5K.
Comments
Do not use the STACKSIZE statement for dynamic-link libraries (DLLs).
Example
This example sets the size of an application's stack to 6,144 bytes.
STACKSIZE 6144
///
e mi sono ricordato che avevo un file *.def poi eliminato dal progetto.
Il problema era proprio lì!!!
Ora funziona perfettamente, ho raddoppiato la dim. dello stack e di HEAPSIZE
,
ma come stabilisco la dim. appropriata?
che svantaggi si hanno a dimensionarle troppo?
EXETYPE         WINDOWS
STUB            'WINSTUB.EXE'
CODE            PRELOAD MOVEABLE DISCARDABLE
DATA            PRELOAD MOVEABLE MULTIPLE
HEAPSIZE        4096
STACKSIZE       16384
EXPORTS         WndProc         @1
Grazie ancora, Fulvio.

Grazie 1000,
Siete stati utilissimi (vedi l'altra risposta).
Ciao, Fulvio.

 
Ma stiamo parlando di Win32, il tema di questo newsgroup, o
del vecchio Windows a 16 bit...?  In Win32, lo stack si
dovrebbe espandere automaticamente quando serve; che
io sappia, i problemi relativi a STACKSIZE erano veramente
tali solo in Win16.
Davvero stai avendo problemi di dimensione stack in un
programma Win32...?!
Alex

 wrote in message
708A17398E28D3119F8...@pces.cadlab.it...
