je repost mon probleme car le titre precedent n'etait pas correct :
 
En fait mon probleme est de creer une tres grand nombre de fenetres dans une appli .... et ca pete a partir d'un certain nombre (plus de 1000 fenetres ...).
 
Ca vient de la limitation du nombre de handle sur des objets GDI : cle GDIProcessHandleQuota dans la base de registre (sous 2000 et XP, car sous NT c'est ProcessHandleQuota ).
 
Bref, dans la msdn ils te disent que tu n'a aucune limitation pour la creation de ressources, mais d'un autre cote, tu n'a qu'un nombre limite de handle graphiques disponibles (maximum 1500 sachant que chaque boite en cree au minimum 5).
 
Si quelqu'un a deja rencontre ce probleme ou sait comment economiser les ressources GDI, je suis preneur ...
 
MERCI !!!!!!

explique un peu pourquoi tu dois créer 1000 fenêtres ...  
 
tu peux toujours faire des contrôles windowless, comme microsoft forms (ce sont les contrôles utilisés dans ie). à part la combobox, ils n'utilisent pas de resources gdi.

OK, je vais voir les microsoft forms ...  
 
Merci
 
ps : pour les 1000 fenetres (parfois c'est meme plus, j'y peut rien... c'est l'appli qui veut ca ....).

détaille, le design n'est sûrement pas optimal. par exemple, si tu affiches 1000 images c'est largement mieux de créer un dc, une dib & co puis de stocker les images dans des buffers plutôt que dans des hbitmap.

les forms c'est un exemple, ça ne gère que les contrôles bouton / radio / textarea & co je crois.

le but est de permettre a l'utilisateur de creer autant de fenetres qu'il le souhaite qui se composent simplement de bouton, de simples edit, ...
 
vraiment que des choses basiques ...
 
pour tester et trouver que le pb venait des ressources GDI j'ai fait un petit prog qui ajoutait violemment des centaines de fenetres contenant 1 edit et 3 boutons.
/*******************
CDialog* CTestView::addBoiboite(int i)
{
CDialog* dlg = new CDialog("toto", this);
dlg->Create(IDD_DIALOG1/*,this*/);
dlg->MoveWindow(0, 0 , 150, 70,TRUE);
dlg->SetWindowPos(&wndTop,0,0,0,0,SWP_NOSIZE | SWP_NOMOVE);
char* titre = new char[10];
itoa( i, titre, 10 );
dlg->GetDlgItem(IDC_EDIT)->SetWindowText(titre);
return dlg;
}
********************/
 
 
Bien evidemment les ressources GDI s'epuisent alors rapidement ...
 
 
je voudrais alors depasser cette limite en partageant les ressources entres les boites ??? ou autrement (econonmiser les ressources GDI, etc ...).
 
Je recherche dans ce que tu m'a propose, mais je reste ouvert a d'autres propositions ....
 
MERCI

et pourquoi voudrait-il en créer 1000 ?
 
pour voir l'état des resources sous windows, il y a le "resource meter" sur le cd d'install. ça détaille les resources gdi, fichiers & co.

 
 L'UTILISATEUR FINAL A TOUJOURS RAISON !!!!!  

 
 
Nan
 
regarde 3ds, sous 98 tu ne peux le lancer qu'une fois a cause du nb de ressource gdi. Ben toi tu dis pareil. en plus, ca fait tres pro, tres classe

velleronnais a écrit a écrit : L'UTILISATEUR FINAL A TOUJOURS RAISON !!!!!

non. c'est ton devoir de programmeur de dire que telle solution est inadaptée, bref d'appuyer tes connaissances. si ton client se fait opérer un jour, il va pas filer ses recommandations au chirurgien avec un petit air supérieur. là c'est pareil.
 

je dirais plutôt que c'est parce que c'est programmé comme de la ... hmmm ... comment dire ...

 
Non l'utilisateur final ne connait rien aux contraintes techniques.

youdontcare a écrit a écrit :   je dirais plutôt que c'est parce que c'est programmé comme de la ... hmmm ... comment dire ...

 
Bah au début je trouvais ca tordu comme pas deux, leur architecture, pis a la longue on s'y fait j'l'aimerais presque bien (je me le tape depuis la version 2 )
ce qui me fait rigoler c'est que je le connais plus de l'interieur que d l'exterieur ce soft (je peux faire des plug in pour, mais faut pas me demander de faire autre chose qu'un teapot avec une sale texture mal mises )
 
 
 
 

chrisbk a écrit a écrit : Bah au début je trouvais ca tordu comme pas deux, leur architecture, pis a la longue on s'y fait j'l'aimerais presque bien (je me le tape depuis la version 2 )

la 2, version dos ? me too je trouve l'architecture très bien foutue, c'est l'implémentation qui me titille parfois. tu tombes sur des gros hacks pour qu'un objet A référencé par B ait une référence vers B -> copie bourrine de pointeur et la source de l'importeur / exporteur 3ds est à elle seule un grand moment.
 

chrisbk a écrit a écrit : ce qui me fait rigoler c'est que je le connais plus de l'interieur que d l'exterieur ce soft (je peux faire des plug in pour, mais faut pas me demander de faire autre chose qu'un teapot avec une sale texture mal mises )

+1 (pour qq types de plugins seulement ...)

youdontcare a écrit a écrit : la 2, version dos ? me too je trouve l'architecture très bien foutue, c'est l'implémentation qui me titille parfois. tu tombes sur des gros hacks pour qu'un objet A référencé par B ait une référence vers B -> copie bourrine de pointeur et la source de l'importeur / exporteur 3ds est à elle seule un grand moment.   +1 (pour qq types de plugins seulement ...)

 
ah non, je suis un jeunot, je parlait de 3dsmax2
 
j'ai vaguement titillé du 3ds4 quand je voulais faire un reader .3ds et ca m'a pris tellement le choux que j'ai préféré faire un exporteur 3dsmax (j'ai mis un tps fou a le faire, quand j'y repense c quelque chose le loader du format exporté prenait + de ligne de code que le moteur en lui meme, c t la misere )
 
plug in j'ai fait export/import/utility. j'ai fait deux helpers, ben dieu, que c chiant ! je le recommande qu'en cas d'ennui mortel

>> ah non, je suis un jeunot, je parlait de 3dsmax2
 
tsk tsk
 
>> j'ai vaguement titillé du 3ds4 quand je voulais faire un reader .3ds  
 
je n'ai jamais fait de plug pour 3ds dos, mais le format de fichier j'ai bien souffert avec. au début je n'arrivais pas à chopper les coords de map, je les avais recalculées à la main en pascal
 
>> et ca m'a pris tellement le choux que j'ai préféré faire un exporteur 3dsmax (j'ai mis un tps fou a le faire, quand j'y repense c quelque chose le loader du format exporté prenait + de ligne de code que le moteur en lui meme, c t la misere )
 
pareil. en plus j'étais vraiment pas motivé à l'époque ...  
 
>> plug in j'ai fait export/import/utility. j'ai fait deux helpers, ben dieu, que c chiant ! je le recommande qu'en cas d'ennui mortel
 
import / export, encore pareil. tes helpers t'ont servi à quoi ?

>je n'ai jamais fait de plug pour 3ds dos, mais le format de >fichier j'ai bien souffert avec. au début je n'arrivais pas à >chopper les coords de map, je les avais recalculées à la main >en pascal
 
bah je reloadais péniblement les coords des vtx (peniblment, je merdais dans les chunk parfois ca partait en vrille complet ). Apres des heures d'angoisses j'ai laissé tombé
 
>pareil. en plus j'étais vraiment pas motivé à l'époque ...  
 
Surtout qu'au début, l'archi de 3ds est pas des plus simples (et encore la elle me reserve bien des surprises des fois)
 
 
>import / export, encore pareil. tes helpers t'ont servi à quoi ?
 
la, plus a grand chose, mais ils vont revenir au gout du jour. en fait j'ai un format de fichier decrivant un paysage (une sorte de heightmap, mais en plus large). je pouvais l'importer dans max et l'editer (j'ai bien pense a faire un editeur pour le paysage, mais vu que tout le reste est fait sous max ca me semblait mieux ainsi). Les helpers servaient juste a pouvoir selectionner des secteurs (le terrain etait découpe en tranche de 9x9). Bref avec ca, tu selectionnais pile poile un secteur en moins de deux (et pas une moitié de secteur, ou des blagues du genre), et tu pouvais assigner les textures (+d'autre trucs que j'avais en tete mais qui n'ont jamais servi, comme une sorte de placement automatique de vegetation)
 
C'etait super delire, tu peux pas savoir.....j'ai pas mal fait a la bricole

>> bah je reloadais péniblement les coords des vtx (peniblment, je merdais dans les chunk parfois ca partait en vrille complet ). Apres des heures d'angoisses j'ai laissé tombé
 
tu me rappelles de très mauvais souvenirs à un moment, j'avais recodé la version loader 3ds pascal en asm ... des heures de debug avec les pointeurs. au moins après ça, c'est rentré dans la tête
 
>> Surtout qu'au début, l'archi de 3ds est pas des plus simples (et encore la elle me reserve bien des surprises des fois)
 
clair je me souviens de ma tentative d'export des clés de morphing, une horreur.
 
>> [longue explication sur le terrain]
 
ha oui, tu avais déjà posté un screenshot. bien sympa d'ailleurs ! pas de démo en vue ? si tu fais des fonctions d'édition, ça doit être pour un jeu ... ou toujours le même projet militaire ?
 
>> .....j'ai pas mal fait a la bricole
 
c'est la règle de dev avec max

tu me rappelles de très mauvais souvenirs à un moment, j'avais recodé la version loader 3ds pascal en asm ... des heures de debug avec les pointeurs. au moins après ça, c'est rentré dans la tête
 
 
grand dieux, un loader 3ds en asm ! une seule chose a dire :  
 

 
>clair je me souviens de ma tentative d'export des clés de >morphing, une horreur.
 
C'est terra incognita pour moi. J'avais bien aimé le passage "comment je retrouve les modifiers attachés a un systeme de particule" . j'metais fait une doc dessus tellement j'avais trouvé ca touffu
 
ha oui, tu avais déjà posté un screenshot. bien sympa d'ailleurs ! pas de démo en vue ? si tu fais des fonctions d'édition, ça doit être pour un jeu ... ou toujours le même projet militaire ?
 
thks Ben comme tout ce que je fais c'est en restructuration. depuis le shot que t'avais du voir (je sais pu c lequel) j'ai revu le gen de texture (qui est encore a revoir, a mon gout, meme si il se dépatouille pas trop trop mal quand on le conf bien), bricoler deux trois trucs. Mais y'a encore bpc a refaire. j'avance a tatons. Sinon je fais tout ca pour le fun (je sus encore etudiant), la démo attendra encore un peu deja fo que je finisse mon compilo (je me suis nické par nvidia et son cg de une semaine, j'etait vert )
 
 

>> grand dieux, un loader 3ds en asm ! une seule chose a dire  
 
j'étais jeune et j'aimais souffrir.
 
>> C'est terra incognita pour moi. J'avais bien aimé le  
 
je n'avais pas trouvé de solution clean, ça s'était fini en inclusion des .h du modifier puis cast sauvage
 
>> passage "comment je retrouve les modifiers attachés a un systeme de particule" . j'metais fait une doc dessus tellement j'avais trouvé ca touffu
 
haa, la pile de modifiers c'est consistant.
 
>> la démo attendra encore un peu  
 
ok
 
>> deja fo que je finisse mon compilo (je me suis nické par nvidia et son cg de une semaine, j'etait vert )
 
je n'ai pas encore testé cg. d'après ce que j'en ai lu :
 
- cg n'est pas open source (je crois qu'il filent le code du ... parser. super !)
- cg ne supporte pas le 'multi passe' - si ton shader fait plus de 128 instructions, tu dois t'occuper de combiner les passes, soi-disant "parce que les développeurs que nous [nvidia] avons interrogés voulaient s'en occuper eux-mêmes". mouarf !
 
cg c'est tout jeune, émuler le langage renderman c'est très bien, je doute qu'on ne puisse pas faire autrement (pas forcément mieux, mais plus peut-être plus pratique pour certains, surtout au niveau de la syntaxe - par ex, je trouve le langage de q3 beaucoup + sympa qu'un code C. et ça reste très puissant, certains ont même fait du toon shading avec). bref, t'as de quoi explorer avec ton langage.

j'étais jeune et j'aimais souffrir.
 
ah la, a ce niveau la, c'est rien de le dire
 
 
haa, la pile de modifiers c'est consistant.
ah ben ca occupe lors d'apres midi pluvieux, ca c sur
 
 
 
 
cg c'est tout jeune, [..]du toon shading avec). bref, t'as de quoi explorer avec ton langage.
 
 
actuellement le mien se décompose en deux bouts : un langage genre C compiler en asm VS/PS, et un autre décrivant un materiau (connais pas le langage shader de q3, fodrait que je regarde y'a ptet des trucs a repiquer). Ce dernier permet de gerer les multiples passes en fonction de la carte, de bricoler pas mal de param etc etc. celui ci sera compiler en asm directement (et theoriquement)
 
j'ai encore de quoi m'amuser (j'ai pas commencer la comp asm )
 
 
dis voir, toi, t'as qqchose a me montrer ? tu bosses sur un projet ?
 
 
 
 
 

>> actuellement le mien se décompose en deux bouts : un langage genre C compiler en asm VS/PS, et un autre décrivant un materiau  
 
ça a l'air sympa
 
>> (connais pas le langage shader de q3, fodrait que je regarde y'a ptet des trucs a repiquer).  
 
langage déclaratif, comme le css pour l'html.
 
>> Ce dernier permet de gerer les multiples passes en fonction de la carte, de bricoler pas mal de param etc etc. celui ci sera compiler en asm directement (et theoriquement)
 

 
>> dis voir, toi, t'as qqchose a me montrer ? tu bosses sur un projet ?
 
avec des potes on essaye de monter une boîte depuis ... longtemps plein de gens intéressés qui filent pas de sous pour le dev. là des gens ont l'air _enfin_ ok, donc des trucs à montrer quand le projet sera fini (et c'est pas pour tout de suite !)

et ce serait quoi, le projet, si tu peux en causer ?

je préfère ne pas causer d'un truc qui n'est pas fini, surtout qu'on n'est même pas encore sûrs d'avoir la thune pour le dev ...

et l'économie des handles win32 dans tout ça ?

youdontcare a écrit a écrit : et l'économie des handles win32 dans tout ça ?

moi je dis qu'un utilisateur qui veut 1000 fenetres a besoin de deux choses :
 

• passer a winnt qui permet d'avoir + de handle
• suivre une thérapie  

 
ma foi, ok ! tiens moi au courant, j'aime bien suivre les projets, meme si c du flou complet

pour info, WIN NT WIN 2000, WIN XP, ou autre .. tout le monde a une limitation en ressources GDI... les limitations que j'indiquais, c'etait pour du WIN NT !
 
Et puis a la base, l'etait pas sense faire tant de fenetre le client ... mais avec l'evolution de l'utilisation du soft, le besoin s'est fait sentir ...
 
Comment deviner cette limitation tant que tu te l'est pas prise dans la face ??? Dans la MSDN ils disent pourtant qu'il n'y a pas de limitations pour les ressources si ce n'est la memoire de l'ordi ... or ce nombre max de handle disponible sur les objets GDI (16kO de handle) est bel et bien une limitation ....
 
d'ou mon pb .. et me voila dans le caca  ...