Reprise du message précédent :
pour les skins, g deja commencé a chercher et c vraiment tout con...
 
un simple fichier ini avec ( entre autre) un nom de repertoire qui contient tous les skins, on change de repertoire quand on change de skin.
 
Pour ce qui est plug in :
video : on peut avoir autant de plug ins que de type de media ( ou alors 1 plug in qui contient les ref de plrs medias)
audio : 1 seul plug in => pour les play list, il faut n utiliser qu'un seul player... et winamp + plugin fait deja tout
 
Je pensais faire a peu pres comme tu disais
on scanne les plugin et on lit qq variables :
le nom
la version
le type ( menu => affiche une nouvelle option dans le menu comme acquisition / gravure / import / console / ... ou filtre => lecture de medias du type audio / video / image, necessité de fournir la liste des extensions supportées
les extensions (dans le cas d'un filtre) ss forme d un tableau
 
Pour les plug in menu, le control est passé au menu lorsque l option est selectionnée, pour les plug in filtre le control n est filé au plug in que si on veut lancer l extension associée..
 
Comment tu fais pour installer les dll lorsque tu scanne ton repertoire?
Pcq normalement il faut les faire reconnaitre par le soft????

Oui, de toute façon, ce n'est que de l'ihm, dans un premier temps il n'est pas necessaire de s'acharner dessus.
 

je propose que les plugins soit configurable, c'est a dire un petit fichier ini qui va avec. comme ca, reprenons l'exemple d'un plugin bsplayer, dans le fichier ini on indique .avi et .mpg si l'on veut que les 2 medias soient lu via bsplayer ou alors que .avi si on veut lire les .mpg avec un autre player
 

C'est exactement ca
 

Oui
 

 
http://www.planet-source-code.com/ [...] 9&lngWId=1
 
matte ca

j vais...
 
Ya moyen de faire un plug in qui gere le lcd et un autre l ir...
comme ca le soft est independant... ( surtout si on ajoute par la suite les lecteur dans les dll)
 
Le pb est qu'il faudrait qu'il tourne en // avec les autres plug in et en continu... et qu'il echange des données avec le reste du soft.
 
Comme tu vois, je suis aC newbeeee avec vb.
 
Bon g vu le lien, g pas tout pigé mais je vais me plonger dans le code source...

 
Oui, d'ailleur c'est comme ca que je pensait faire pour le LCD (tlm ne mettra pas un LCD sur sa box, de plus je n'ai qu'un lcd sur port //, si par la suite qqun veut faire un plugin pour un LCD sur port serie ce sera transparent pour le reste de l'utilisation )
 
Sinon, le lien que je t'ai donné presente un source d'une appli mettant en oeuvre un system de plugin comme celui dont je parle a savoir par DLL activeX en fait vu l'appli, c'est plutot un squelette d'appli a plugin

okay, g un truc a finir pour le taff, puis je regarde le code source...
mais g pas vb ici, donc ca sera juste regarder....  
Tu penses coder aussi, ou juste me donner un coup de main de temps en temps ?
 
Je pense qu'il faudrait quasi refaire le prog de A a Z...
c chiant mais ce sera mieux

 
Je pense coder car je dirais que pour moi ca urge, j'en ai marre de voir ma box avec un windows tt con    
 
Sinon, oui et non pour refaire tout de A à Z, j'entends par la que l'on garde tes fonctions mais il faut refaire le squelette du prg pour prendre en compte les plugins

En gros, tu as du voir :
une fonction principale pour la detection de l'insertion...
qui appelle des userform lors d'une insertion / ejection
Donc on garde le main
On ajoute une detection des dll avant
on ajoute l interface graphique apres qui prend en compte les plug ins...
 
Va falloir se decider a prevoir les variables a scanner dans chaque DLL ( et surtout ne pas en oublier

 
Oui, tes fonctions sont ok pour ca, on garde.
Detection des dll -> je propose qu'on utilise un mecanisme de type collection vb(tres efficace)
Gestion de l'ihm -> pour l'instant peu important, il faut juste prendre en compte les plugins, apres, on verra pour les skins.
 
sinon, effectivement il faut se decider pour les "variables" (terme que l'on emploiera plus desormais car on va raisonner en prog objet). Il faut que l'on definisse une structure commune de classe (fichier .cls VB) commune a tout les plugins... a savoir une classe est composé de donnée membres (les "variables" ) et de methodes (les "fonctions" ). Le principe est simple, il faut que les methodes et données membres communes publiques a tout les plugins soient les meme et que l'on protege les methodes propres aux objets (private). On realise ainsi une sorte d'interface commune a tout les plugins avec le soft

pour les skin => okay, suffit de pas mettre les images dans le prog et de donner le nom du chemin dans l ini et le reste se fera par la suite, yaura deja l ossature
 
Pour les plug ins, j avais b1 compris ca
tu peux dvp collectionvb ce que c ?
 
Pour la prog objet, g pas l habitude... mais ca va venir, je connais le principe, (mais pas de pratique    
 
La structure, le main recuperera pour chaque plug ins qq données membres (? c b1 ca?    verifiera le type et la version au cas ou yait plrs fois le mm plug ins, pour la methode, je n en vois qu'une seule : lancer le plugin...
Mais je dois oublier des trucs... manque d habitude.
 
G quasi fini mon truc, je vais pouvoir regarder le code source

faudra que je regarde le code de chez moi, parce que la j comprend pas grand chose...
deja wordpad, c pas genial pour parcourir du code vb...

Oui, c'est pas encore a l'ordre du jour
 

Une collection est un mecanisme de vb permettant de gerer une liste chainée d'objet (insertion,suppression sur des instances de classes)
 

c'est l'ideal pour faire un soft flexible (qui plus est avec des plugins )
 

Sur le principe, c'est exactement ca, effectivement il faut aussi inclure une gestion des versions. Pour LES methodes il y a effectivement le lancement du plugin, mais aussi, par exemple une methode permettant de renvoyer des info vers le soft (utile pour faire un OSD ou une sortir d'info sur un LCD par exemple) voir une methode permettant de killer le player en cours (a l'ejection du cd par ex)
 

ok. Perso, je pourrais rien commencer reellement avant lundi

okay
ben ca resous ma question de comment faire discuter les plug in et le main...
donc  
1 => passer la main
2 => recuperer des infos (LCD)
3 => envoyer des infos (clavier / telecom IR)
4 => killer le process / reprendre la main
 
Moi je vois essayer de me familiariser avec les dll /ocx pendant ce WE... mais je risque de ramer...

Vous voulez pas essayer en c++ ?

 
aucun interet pour ce genre d'appli... pourquoi prendre un marteau pour enfoncer une punaise ?

Je parlais ds le sens ou vous pourriez faire de la POO...
 
VB, tu sé, la POO, c pas sons genre
 
Mais bon, sinon, je ferais bien parti de votre projet mais il faudrait mettre à plat les spécificités.

ben ya pas de pb...
vous n avez qu a me rejoindre sur www.mmbox.fr.St
ya une rubrique windows qui est prete...
 
Je pense que les dll, qu elles aient ete faites en vb ou en vc++, c pareil, donc une fois que le coeur est fait, les dll sont faisables en n'importe quoi...
Mais je me trompe peut etre..
 
Sinon ya pas de pb, dams tu t inscrit sur mmbox et on continue le topic la bas...
 
Sinon Ben Je dirais presque qu'il y a une team WinMMbox qui se créé....
 
-------------
G ouvert la bas un topic recapitulatif...

c parti!!!
 
Sinon, on va finir par inonder le topic
 
Petite parénthèse sur ce topic : je continue qd même mon prog Dexec et il restera sans prétention particulière face aux projets précedemment discutés, mais pratique pour une DivxBox light si je puis dire ou un pc classik.

okay
moi, le mien je vais le clore tel qu'il est actuellement, puis préparer la base pour qu'il puisse accueillir l'interface suivante
(CA me ferait mal au coeur de jeter tout ce que g fait..... mes debuts en VB, ca meriterait d etre encadré au mur......)
 
Rendez vous la bas...

je me suis inscrit ( cf ma réponse à ton post de l'équipe )

Yep, on n attend plus qu ixemul, qui est nommé madwolf chez nous...