PureBasic

Bonjour,

Voilà: j'ai développé un petit logiciel qui est composé d'une fenêtre principale contenant des menus. Quand on sélectionne (clic) un menu, je fais exécuter un programme. Exemple:

Code : Tout sélectionner


;Code de ma fenêtre principale
Global wVar
wVar=1

;Bla... Bla... Bla...

Select Choix
Case 1
       RunProgram("Prog2.exe")
Case 2
       RunProgram("Prog3.exe")
Case 99
       WQuit=1 (cela permet de quitter le programme principal)
EndSelect

;etc..
END

1. Ma question est la suivante: dans le programme (Prog2), est ce que la valeur de wVar est perdue ?

2. Dans ma fenêtre principale j'utilise évidemment le select et case (pour les menus). Mais dans le programme que j'appelle (Prog2), j'utilise aussi la select et case (pour les évènements), parmi ces cases il se pourrait que la valeur soit la même que dans le programme principal. Ma question:

Est-ce que le case (la valeur du cas) du programme principal n'entre pas en conflit avec celle du programme appelé?

3. Dernière question:
Mon programme principal utilise une fenêtre classique. Je viens de remarquer l'existence d'une fenêtre nommée MDI dans l'aide du PB. Selon vous, que dois je utiliser de préférence ? MDI ou classique pour mon programme principal? et pourquoi?

Peut on ajouter une image de fond sur une fenêtre MDI (j'ai fait un test mais sans resultat)

Merci de vos réponses

Anissa
e

Bonjour annissa !
JE vais déjà commencer par répondre à votre dernière question à propos des fenêtres
mdi.
Comme vous avez vu dans l'aide, une fenêtre mdi, n'est pas une fenêtre mais un gadget
qui permet d'allouer dynamiquement un espace qui sera réservé pour créer des fenêtres
filles à l'INTérieures d'une fenêtre mère.
Ce type de fenêtre ou gadget se trouve généralement dans des applications
de type "bloc-note", où chaque fenêtre fille pourra, par exemple,
contenir un document de travail
ouvert par l'utilisateur. Une fois son travail terminé,
celui-ci pourra refermer cette fenêtre "mdi",
pour en ouvrir un autre...
La fermeture de ce gadget n'entraînera pas la fermeture
de la fenêtre principale du bloc-note.
Ce gadget spécial (appelé "multi document interface"), se différencie des fenêtres
classiques car il ne renvoie pas d'évènements.
c'est les gadgets présents à l'INTérieure de
la fenêtre "mdi", qui le font. Autrement dit, LES gadgets "mdi"
ne peuvent pas être contrôlés par une procédure de type
"callback", et comme elles ne génèrent pas d'évènements,
LES "mdis", n'ont pas de file d'attente des évènements. Donc elles ne seront pas contrôlables
par des commandes de type "waitwindowevent".
De plus, comme elles n'ont pas de file d'attente des évènements,
elles ne pourront pas recevoir d'évènements
provenant du système d'exploitation.
Et comme LES "mdigadgets", ne sont pas considérés comme
des fenêtres principales, ils ne seront pas ratachés
à un thread.
De plus, comme un "mdi" est un gadget et non une fenêtre,
il ne pourra pas être utilisé comme fenêtre principale
dans votre programme principal, ni dans aucun autre, d'ailleurs !

Nous allons maintenant aborder vos deux questions précédentes.
Ce n'est pas évident à expliquer, mais je vais essayé de le faire le plus simplement possible.
Tout d'abord, je tiens à m'excuser auprès des puristes, car LES explications
qui viennent, ne sont pas extraites de livres mais sont fondées d'après mes propres
expériences.
Comme vous le savez probablement, windows peut être considéré
comme un "arbre" où le tronc serait
le système d'exploitation. Chaque branche de l'arbre,
est une application, chaque feuille située sur cette branche,
peut être considéré comme un gadget ou élément de l'application...
Ce qui signifie que l'on a la structure suivante :
"système d'exploitation"\"application"\"gadgets".
Lorsque vous exécutez un programme exécutable sur votre ordinateur,
le système d'exploitation va lui créer un thread.
Il va ensuite lui allouer une zône mémoire,
qui ne sera accessible que par lui, et qui ne contiendra que LES données le concernant.
En effet, windows est un système d'exploitation qui travaille en mode dit "protégé".
C'est la raison pour laquelle, un programme secondaire ne pourra pas accéder aux variables
d'un programme primaire.
Si vous voulez transférer des données à un programme
exécuté par la commande "run", vous devez transmettre des paramètres à votre
programme appelé comme ceci :

Code : Tout sélectionner

Global wvar.b ; je lui donne un type
wvar=1
RunProgram ("c:\programme2.exe",Str(wvar))
; même si on passe des chiffres comme paramètre,
; la commande "runprogram" ne peut transmettre
; que des chaînes de caractères
; au programme appelé.

De plus, chaque programme exécuté à un handle de fenêtre unique.
Et chaque thread, possède sa propre file d'attente des évènements.
Donc, le programme appelé ne devrait pas créer de conflits avec le programme appelant,
en ce qui conserne LES conditions, et LES évènements des gadgets.
Même si la commande "runprogram", est pratique pour chaîner des programmes,
elle présente le désavantage de consommer beaucoup de ressources à la machine.
En effet, le temps du dos est fini ! et LES ".bat" également !
l'exécution de plusieurs programmes en même temps, oblige un partage des ressources
matérielles, mais également une consommation importante des processeurs.
Si vos programmes que vous allez appeler depuis votre menu principal sont
tous écrits en purebasic, JE vous conseille de mettre chaque programme
dans un module ".pbi".
Chaque module commencerait par la ligne suivante :

Code : Tout sélectionner

; module2.pbi
Procedure .l prog2 (param.b)
Protected erreurlevel.l ; code de sortie
; ici mettez le code de "prog2"
ProcedureReturn erreurlevel
EndProcedure

Dans votre programme principal il ne vous restera
qu'à inclure les modules
XIncludeFile ("module2.pbi")
Global wvar.l = 1
Global erreurprog2.l

; ici, vous mettez votre code du programme principal
; vient ensuite l'exécution de "module2"
Select Choix
Case 1
erreurprog2 = Prog2 (wvar)
Case 2
erreurprog3 = Prog3 ()
Case 99
WQuit=1 (cela permet de quitter le programme principal)
EndSelect
;etc..
End [/code]

chaque programme (.exe) est totalement indépendant d'un autre.
Je peux par exemple lancé 2 fois un même programme *.exe, chaque programme aura ses propres valeurs. il n'y a aucune collision possible.

Par contre, j'ai l'impression que tu cherches à lancer plusieurs programme pour pouvoir ouvrir plusieurs fenêtres.
On peut très bien ouvrir plusieurs fenêtres dans le même programme.
Surtout que si as besoin de faire des échanges d'informations entre tes fenêtres, il est bien plus difficile de la faire entre 2 *.exe

j'ai attrapé le premier programme que j'avais avec plusieurs fenêtres pour te faire un exemple.

Code : Tout sélectionner

; Création des fenêtres et des GadgetList
If OpenWindow(0, 100, 100, 100, 100, "Test", #PB_Window_BorderLess | #WS_SYSMENU) = 0
  End
EndIf
CreateImage(0, WindowWidth(0), WindowHeight(0))
StartDrawing(ImageOutput(0))
  Box(0, 0, WindowWidth(0), WindowHeight(0), RGB(0, 0, 255))
StopDrawing()
ImageGadget(0, 0, 0, 0, 0, ImageID(0))
If OpenWindow(1, 300, 100, 100, 100, "Test2", #PB_Window_BorderLess | #WS_SYSMENU, WindowID(0)) = 0
  End
EndIf
CreateImage(1, WindowWidth(1), WindowHeight(1))
StartDrawing(ImageOutput(1))
  Box(0, 0, WindowWidth(1), WindowHeight(1), RGB(0, 255, 0))
StopDrawing()
ImageGadget(1, 0, 0, 0, 0, ImageID(1))
If OpenWindow(2, 100, 300, 100, 150, "Test3", #PB_Window_BorderLess | #WS_SYSMENU | #WS_BORDER, WindowID(0)) = 0
  End
EndIf
CreateImage(2, WindowWidth(2), WindowHeight(2))
StartDrawing(ImageOutput(2))
  Box(0, 0, WindowWidth(2), WindowHeight(2), RGB(255, 0, 0))
StopDrawing()
ImageGadget(2, 0, 0, 0, 0, ImageID(2))
If OpenWindow(3, 300, 300, 150, 100, "Test4", #PB_Window_BorderLess | #WS_SYSMENU | #WS_SIZEBOX, WindowID(0)) = 0
  End
EndIf
CreateImage(3, WindowWidth(3), WindowHeight(3))
StartDrawing(ImageOutput(3))
  Box(0, 0, WindowWidth(3), WindowHeight(3), RGB(255, 255, 0))
StopDrawing()
ImageGadget(3, 0, 0, 0, 0, ImageID(3))



; Boucle d'évènement
Repeat
  Event = WaitWindowEvent()
  
  Select Event
		Case #PB_Event_Gadget
      Select EventWindow() ; Quelle fenêtre ?
				Case 0 ; Fenetre 0
					Select EventGadget() ; Quel gadget ?
						Case 0 ; Gadget 0
							Select EventType()
								Case #PB_EventType_LeftClick
									Debug "Gadget 0, fenetre 0"
							EndSelect
					EndSelect
				Case 1 ; Fenetre 1
					Select EventGadget()
						Case 1
							Select EventType()
								Case #PB_EventType_LeftClick
									Debug "Gadget 1, fenetre 1"
							EndSelect
					EndSelect
				Case 2 ; Fenetre 2
					Select EventGadget()
						Case 2
							Select EventType()
								Case #PB_EventType_LeftClick
									Debug "Gadget 2, fenetre 2"
							EndSelect
					EndSelect
				Case 3 ; Fenetre 3
					Select EventGadget()
						Case 3
							Select EventType()
								Case #PB_EventType_LeftClick
									Debug "Gadget 3, fenetre 3"
							EndSelect
					EndSelect
			EndSelect
	EndSelect
  
Until Event = #PB_Event_CloseWindow

End

Ensuite, le système MDI, c'est le principe de Word par exemple, une fenêtre principale dans laquelle on peut créer d'autre fenêtre.
Comme cet exemple

PureBasic

Fenêtre MDI ou fenêtre normale ?

Fenêtre MDI ou fenêtre normale ?

Re: Fenêtre MDI ou fenêtre normale ?

Re: Fenêtre MDI ou fenêtre normale ?