PureBasic

ça serait bien un delay(0) pour ne pas monopoliser trop de resources dans la procédure waituntilwindowisclosed().

WaitUntilWindowIsClosed chez moi ne monopolise aucune ressouce

ProcedureDLL WaitUntilWindowIsClosed()
  Repeat
  Until WaitWindowEvent()= #PB_Event_CloseWindow
  ProcedureReturn 1
EndProcedure

Oui, mais un delay serait bien je pense quand même. Chez moi, au bout d'un certain temps, si j'utilise ta fonction, ça rame bcp... mais je dois être le seul, encore une fois.

WaitWindowEvent attend un évènement, ce qui évite d'ajouter un delay

c'est louche

Salut
Ca serait bien d'ajouter une fonction RunOnce un peu différente :
Le contrôle s'effectue sur le nom du fichier et non pas sur le nom de la fenêtre.

J'ai pas compris ta question

il veut dire que si deux fenetres ont le même nom le runonce peut poser problème... (conflit avec d'atres applis)

Dri

Oui voilà.
Et moi j'aurai besoin d'un RunOnce sur le programm en lui même car le titre de ma fenêtre principale change sans arrêt...

suggestion :
tu énumères les process en cours, tu tu récupère le nom de leur exécutable, s'il correspond au tien tu gères en conséquence

mais je sais pas si c'est faisable...

Dri

OK j'avais pensé que tu voulais pouvoir lancer ton executable au démarrage de windows 1 seule fois, en fait tu veux empêcher l'exécution du programme une seconde fois.

J'ai ce code que j'ai prévu d'inclure dans la prochaine version de la DroopyLib

Code : Tout sélectionner

; Author : netmaestro
; End the Program if another instance is found !!

Procedure RunOnlyOneInstance()
*a = CreateSemaphore_(null,0,1,GetProgramName()) 
If *a <> 0 And GetLastError_()= #ERROR_ALREADY_EXISTS 
  CloseHandle_(*a) 
  End
EndIf
EndProcedure


;/ Test
; RunOnlyOneInstance()
; OpenWindow(0, 100, 200, 195, 260, #PB_Window_SystemMenu | #PB_Window_MinimizeGadget | #PB_Window_MaximizeGadget, "PureBasic Window")
; WaitUntilWindowIsClosed()

Version 1.24 disponible

BlockInputW98
FormatDisk
GetGadgetIdentifier
GetPixelColor
GetUserLanguage
GuidAPI
MonitorPower
RealDriveType
RunOnlyOneInstance
RunProgramAtStartup
URLDownloadToFile
WMI

LDB ( DATABASE FUNCTIONS )
LdbGetPointer
LdbSetPointer
LdbCountField
LdbOpen
LdbCreate
LdbCountRecord
LdbRead
LdbWrite
LdbAddRecord
LdbDeleteRecord
LdbSaveDatabase
LdbCloseDatabase
LDBSetFieldName
LdbGetFieldName
LdbPreviousRecord
LdbNextRecord
LdbInsertRecord
LdbAddField
LdbDeleteField
LdbSearchInit
LdbSearch
LdbSortNum
LdbSortAlpha

TOOLTIP FUNCTIONS
ToolTipAdd
ToolTipRemove
ToolTipChange
ToolTipShow
ToolTipHide

Droopy, ya déjà une fct API qui s'appèle URLDownloadToFile_().
Ca risque pas de poser des conflits ?

bah y'a un _ de différence nan ?
et pis y'a des chances que sa fonction ne soit qu'un appel vers celle de l'api... là où ca devient intéressant c'est si son CHM est bien documenté sur la fonction!!

Dri

C'est en effet cette fonction de l'API qui est utilisée, mais ensuite le cache est vidé ( au cas ou le cache serait corrompus )

Code : Tout sélectionner

; Author : BackupUser
  ProcedureDLL URLDownloadToFile(Url.s,File.s)
  retour=URLDownloadToFile_(0, Url, File, 0, 0)
  DeleteUrlCacheEntry_(Url)
  If retour=0 : retour=1 : Else : retour=0 : EndIf
  ProcedureReturn retour
EndProcedure

Il n'y a aucun risque de conflit car il y a le _ de différence

Non, je n'ai rien dis

Il me semblait avoir eu un conflit de ce style une fois, mais j'ai dû réver (je ne retrouve plus le bug...)

PureBasic

Droopy's Lib