| |
|
|
Edelpfuscher | moin moin! es écrit et grüßt stefan, 44 jahre, bits'n'bytes-verwurschtler aus hamburg.
brauche im job une bildbetrachter avec den anforderungen: fonctionne sous den meisten win-versionen, fix, tauglich pour alle gängigen formate, höhe/breite einpassen, zoomen, scrollen, fokus à aufrufende app zurückgeben, standalone, single-instance ... et zwar ausschließlich comme kommandozeilen-tool. (cela ginge theoretisch aussi alles avec Irfan, allerdings ist qui viel trop mächtig. il y a oui presque keinen buchstaben, qui chez ihm pas comme - bisweilen fataler - shortcut herhalten muss.)
après que cela halbe inet durchforstet hab et alle downloads vergeblich ausgetestet étions, stand fest: selbermachen. irgendwo fand sich ensuite aussi dans den gesammelten werken qui eingestaubte XProfan-cd (version 8.0) et cela grundgerüst était erstaunlich vite zusammen(-geklaut, merci bien à qui gemeinde!), so large - si bien.
probs: - sans 'SetAutoPaint 0' était gar nix avec neuzeichnen - avec flackert's droite réglé - qui geschichte avec qui einmaligen instanz veux simple pas richtig funzen
den fred 'Doppelstart Instanzen plusieurs Programmstarts Verhindern' habe je hoch et runter durchgekaut - merci nochmals à qui spezialisten! sauf dem ansatz avec FindWindow (im beispiel auskommentiert, weil trop lente) flogen mir qui speicherverletzungen seulement so à ohren.
favorisieren serait je un verhalten: vieille instanz(en) bemerken et finissons.
sur weitere tipps, anregungen, beispiele suis je mich déjà, merci et horrido! |
|
|
| |
|
|
|
| Grüße!
il y a pas wirklich une toujours funktionierende Possibilité, une solchen
Doppelprogrammstart Windows-Versionen-übergreifend 100%ig zuverlässig
trop verhindern. tu peux user32::FindWindow benutzen mais aussi hierauf peux
Du toi aus verschiedenen Trouvé pas 100%ig sortir de. Peut-être es
encore relativ sûrement per TimerProc qui regelmäßg (z.B. einmal pro seconde) per
FindWindow findet et ggf. une finissons-nouvelle sendet. Mutexe trop
Programmstart ou bien Speicherdateien sommes pas "sicherer" là dans neueren Windows-
Versionen de Prozess trop Prozess différent Zugriffsrechte pas toujours
vorhanden son doit. SetAutoPaint 0 zeichnet rien récente, tout autor oui 0.
une Fenêtre-APP soll cela la fenêtre selbst récente zeichnen si es qui nouvelle
en supplément bekommt. Du könntest hierzu alors avec SubClassing travailler si Du pas
sur dem hWnd zeichnen vouloir. je serait chez Deinem Beispiel wohl simple sur
dem hWnd zeichnen et %hDC2 sowie %HDC gleichermaßen décrire sodass
XProfan sich selbst um cela Neuzeichnen des %hWnd kümmern peux. |
|
|
| |
|
|
|
Edelpfuscher | besten dank!
et: tant pis, tant pis - qui schlechten nachrichten J'ai eu befürchtet. es kursieren oui diverse 'single instance dlls' - daher entstand qui schwache espoir, dass es irgendwie stabiler et allgemeingültiger trop faire wäre. (es muss oui s'il te plaît pas juste c# son...)
cela aufrufende HTA jongliert déjà avec reichlich anderem kram herum et sollte de solchen aufgaben qui 'instanz-kontrolle' eigentlich verschont rester. Minuteur wären wohl dans chaque le cas trop lente, là z.b. une 180°-drehung ggf. seulement qui zeitspanne eines doppelklicks ausmacht, et dabei peut-être. déjà deux aufrufe absetzt.
immerhin: den zusammenhang avec '%hDC2 sowie %HDC' hab je un paire male verfolgt et doch pas wirklich kapiert. muss je wohl nochmal aufgreifen... :o)
horrido! |
|
|
| |
|
|
|
E.T. |
... favorisieren serait je un verhalten: vieille instanz(en) bemerken et finissons ...
je denke, voilà wohl qui FindWindow-variante qui beste. je löse cela jusqu'à maintenant toujours so (pour bessere Varianten suis je gern lernfähig), et ca hat jusqu'à Win 7 jusqu'à maintenant aussi encore aucun Probleme verursacht. Bien sûr sollte cela eigene Progg-la fenêtre pas justement "Explorer" ou bien so benannt volonté...
avec cette Verfahrensweise ist es mir aussi encore nie passiert, cela plusieurs Instanzen cela Proggs am werkeln étions, weil oui qui seule laufende chez Neustart des Proggs gekillt wird. et qui sur numéro sûrement aller veux, peux oui pour dem "killen" einer vorhandenen Instanz qui cherche encore 3x wiederholen |
|
|
| XProfan X2Grüße aus Sachsen... Mario WinXP, Win7 (64 Bit),Win8(.1),Win10, Win 11, Profan 6 - X4, XPSE, und 'nen schwarzes, blinkendes Dingens, wo ich das alles reinschütte... | 06.11.2012 ▲ |
|
|
|
|
Jörg Sellmeyer | je hab aucun Solution pour cela Problem mais une Possibilité, comment qui Findwindow-Solution plus rapide volonté pourrait. Anstatt cela d'abord aufgerufene Programme trop finissons et cela neue Bild par cela zweite Programme Montrer trop laisser, peux cela zweite Programme pour erfolgtem Check sur Vorhandensein des ersten, diesem simple cela neue Bild comme paramètre transfert et sich ensuite wieder selber finissons. cela erste Programme stellt ensuite cela Bild dans gewünschter Taille dar. là muss ensuite pas nochmal qui Programmoberfläche aufgebaut volonté, au cours de parallèle cela este Programme geschlossen wird. |
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 06.11.2012 ▲ |
|
|
|
|
Edelpfuscher | moin et merci nochmals.
qui cherche pour vorhanden instanzen wird oui pas dreimal wiederholt, mais so souvent comment nötig:
Tandis que (@FindWindow("iv") > 0) MyHandle& = @FindWindow("iv") Poster un message(MyHandle&, $10, 0, 0, 0) Wend
oui c'est ca cela führt zum problem: entre cette schleife et dem aufspannen des neuen, 'findbaren' fensters avec titel vergeht ggf. so viel zeit, dass qui doppelstart plan doch pas sûrement vermieden volonté peux. cela 'findbare' Fenêtre füher trop mettons (et naturellement vom kill auszuschließen), führt trop einer augenkrebs-verdächtigen flackerei.
pourrait peut-être. une 'kill-message' ($10, $12, etc.) plus rapide son comme une autre?! ou bien liegt qui flaschenhals, comment trop vermuten wäre, doch chez FindWindow selbst?
cela senden qui paramètre de instanz 2 à nr. 1 wäre sûrement richtig knorke, justement aussi bezügl. des flackerns. mais comment bekomme je sur possible vielen windoof-versionen qui paramètre heil rübergeschaufelt? gibt's là quelque chose 'halbwegs' sicheres?
horrido! |
|
|
| |
|
|
|
| comment funktioniert ca ici chez Dir?
Télécharger KompilierenMarqueSéparation {$cleq}
const appTitle="myApp"
const checkVersionMsg=wm_user+1234
//
windowstyle 1 | 2 | 4 | 8 | 16 | 512
windowtitle appTitle
cls
userMessages wm_close,checkVersionMsg
// Adresse nativer Proc beziehen und Opcode abholen
long myNativeTimerProcOpcode=globalAlloc(gPTR,1024)
rtlMoveMemory(myNativeTimerProcOpcode,procAddr(myNativeTimerProc),1024)
//Opcode patchen und Startzeit nativ hinterlegen
long myNativeTimerProcOpcode&,7=getTickCount
// nativen Timer erzeugen ud auf Opcode lenken
~setTimer(0,0,333,myNativeTimerProcOpcode)
do {
waitinput
select %uMessage
caseof wm_close : break
caseof checkVersionMsg
case &ulParam<long(myNativeTimerProcOpcode,7) : break
endSelect
}
end
nProc myNativeTimerProc(long wnd,uMsg,idEvent,dwTime){
push $FFFFFF
pop eax
long myTime=eax
long chk=findWindowX(appTitle)
//
case chk : sendMessage(chk,checkVersionMsg,0,myTime)
}
// https://xprofan.com/intl/de/quelltexte/findwindow-findwindowx-nproc-xprofan/
nProc findWindowX(string s){
case s=="" : return 0
long lst=dim(16)
long lst&,0=0,addr(s),dim(512),len(s)
enumWindows(procAddr(findWindowX.enumProc),lst)
long h=long(lst,0)
dispose(long(lst,8))
dispose(lst)
return h
}
nProc findWindowX.enumProc(long wnd,lst){
PushAll
if wnd==hWnd {
popAll
return true
}
long r=getWindowTextLength(wnd),\
l=long(lst,12)
if r<l {
PopAll
return true
}
ifnot r==getWindowText(wnd,long(lst,8),511) {
PopAll
return true
}
if char(long(lst,4),0,l)==char(long(lst,8),0,l) {
long lst&,0=wnd
PopAll
return false
}
PopAll
return ss=s4 href='./../../funzione-riferimenti/XProfan/vrai/'>vrai
}
avec cela qui Voir le texte source chez Dir fonctionne musst XProfan avec XPSE pimpen: [...] -
mais peux oui erstmal qui Exe testen.
chez diesem Code bleibt qui älteste Instanz conservé.
peux aussi léger umgestellt volonté sur: Aîné finissons & Neuere conservé
sur jeden le cas verursacht cette Code aucun Systemlast et arbeitet quasi im
Hintergrund passif et delegiert seulement cela Programmbeenden. peux oui la fois
im Explorer sur qui Test.Exe avec qui Entertaste draufbleiben sodass joli
viele Instanzen erzeugt volonté - peux on zusehen comment vous alle wieder verschwinden/
zuverlässig abgearbeitet volonté et seulement qui Erste übrig bleibt. |
|
|
| |
|
|
|
Edelpfuscher | très cool, merci!
rennt comment gewünscht, maintenant muss je seulement encore doch den code durchsteigen... et cela wird, wie's aussieht, une ganze weile dauern... ;o)
rückmeldung folgt... |
|
|
| |
|
|
|
| Wenns erstmal grundsätzlich so funzt comment de Dir gewünscht ensuite simple encore fix
durchgeben quoi encore trop erledigen ist là je cela ensuite fix avec einbauen serait.
Beispielsweise devrait cela "neuere" la fenêtre garnicht seulement erscheinen si bereits
une vorhanden ist. cela hilfreiche à diesem Code ist dass cela XProfan-Programme
selbst eigentlich rien trop 1faire hat ausser trop regarder si une UserMessage
checkVersionMsg vorliegt et es sich finissons sollte si &ulParam <
long(myNativeTimerProcOpcode,7). |
|
|
| |
|
|
|
Edelpfuscher | qui versprochene rückmeldung:
mon wissensrückstand bezügl. XPSE et aktuelleren Profanversionen ist offensichtlich viel trop grand, um dans angemessener zeit trop einem brauchbaren ergebnis trop venons.
kümmere mich alors mittlerweile à anderer lieu um cela tuer überzähliger instanzen et lebe avec qui krücke (qui soweit zufriedenstellend et stabil fonctionne).
nochmals merci bien pour qui tipps et anregungen. quand je en supplément venons werde, mon profanes halbwissen trop vertiefen, bleibt malheureusement ungewiss.
horrido! |
|
|
| |
|
|