|
| Forskel på form. Fra : Rasmus |
Dato : 05-06-05 12:54 |
|
Hej.
Hej, jeg bruger bcb6.
Jeg prøver at få en form til at ligge on top (visuelt) af en
anden application (background program). Dette kan sagtens lade
sig gøre hvis formen bliver lavet i en dll loadet af backgound
programmet, men hvis jeg prøver at ligge den on top fra en
stand alone exe, vil background programmet ikke "acceptere" min
form.
Jeg har en stand alone exe som laver formen (eks 1):
Application->CreateForm(__classid(TForm1), &Form1);
1->ParentWindow = BackGroundHWND;
Form1->Show();
Eller jeg fra en dll laver formen på samme måde (eks 2):
Application->CreateForm(__classid(TForm1), &Form1);
Form1->ParentWindow = BackGroundHWND;
Form1->Show();
I eksempel 2 bliver formen lavet fra background programmet (loadet
via en dll).
I eksempel 1 fra en exe fil.
Til forskel fra hvad der sker i eksempel 2, så sker der i eksempel
1, når jeg prøver at få min form til at ligge on top fra stand alone
programmet, det at background programmet ikke vil acceptere min form.
Den vises on top, men hvis man klikker på min form minimeres
backgroundprogrammet sammen med min form. Dette sker ikke
hvis jeg laver min form fra en dll.
Mit spørgsmål går så på, hvad er forskellen på at lave formen
fra dll'en og lave den fra et stand alone program? Er det
noget med hvilken owner der er, eller? Og hvad skal jeg gøre
for at background programmet accepterer at min form skal ligge
on top?
På forhånd tak!
Mvh. Rasmus
| |
Mogens Hansen (05-06-2005)
| Kommentar Fra : Mogens Hansen |
Dato : 05-06-05 16:15 |
|
>
> "Rasmus" <fsim@ofir.dk> wrote in message
> news:1117972456.870182.112540@o13g2000cwo.googlegroups.com...
> Hej.
>
> Hej, jeg bruger bcb6.
> Jeg prøver at få en form til at ligge on top (visuelt) af en
> anden application (background program). Dette kan sagtens lade
> sig gøre hvis formen bliver lavet i en dll loadet af backgound
> programmet, men hvis jeg prøver at ligge den on top fra en
> stand alone exe, vil background programmet ikke "acceptere" min
> form.
Er background programmet et program du har skrevet ?
Hvis du laver en exe-fil vil dit program køre som sin egen process.
Hvis du laver et DLL, som kaldes fra et andet program (f.eks. Excel) vil det
ske i scope af den process.
> Jeg har en stand alone exe som laver formen (eks 1):
> Application->CreateForm(__classid(TForm1), &Form1);
> 1->ParentWindow = BackGroundHWND;
Er dit baggrunds vindue et ikke VCL baseret vindue ?
Hvis det er VCL baseret, er det sikkert bedst at "Parent".
> Form1->Show();
>
> Eller jeg fra en dll laver formen på samme måde (eks 2):
> Application->CreateForm(__classid(TForm1), &Form1);
> Form1->ParentWindow = BackGroundHWND;
> Form1->Show();
>
> I eksempel 2 bliver formen lavet fra background programmet (loadet
> via en dll).
> I eksempel 1 fra en exe fil.
> Til forskel fra hvad der sker i eksempel 2, så sker der i eksempel
> 1, når jeg prøver at få min form til at ligge on top fra stand alone
> programmet, det at background programmet ikke vil acceptere min form.
> Den vises on top, men hvis man klikker på min form minimeres
> backgroundprogrammet sammen med min form. Dette sker ikke
> hvis jeg laver min form fra en dll.
>
> Mit spørgsmål går så på, hvad er forskellen på at lave formen
> fra dll'en og lave den fra et stand alone program?
Der burde ikke være nogen forskel.
Normal vil man putte VCL baserede klasser i en package (som blot er en
speciel form for DLL).
> Er det
> noget med hvilken owner der er, eller?
Nej
> Og hvad skal jeg gøre
> for at background programmet accepterer at min form skal ligge
> on top?
Det kommer an på hvad du prøver at lave.
Er det en udvidelse til et eksisterende program som du ikke har fuld kontrol
over (oversætter), skal det laves som et DLL.
Hvis du har fuld kontrol over sourcekoden til programmet har du frit slag
mellem at placere en form i EXE-filen eller i en package (BPL).
| |
Rasmus (05-06-2005)
| Kommentar Fra : Rasmus |
Dato : 05-06-05 17:58 |
|
Hej, tak for svaret!
>Er background programmet et program du har skrevet?
Nej, det skrevet i MS Visual C++, sandsynligvis med
noget DirectX kode, hvis det har nogen betydning?
>Er dit baggrunds vindue et ikke VCL baseret vindue ?
Yeps. Nok noget DirectX kode.
>Er det en udvidelse til et eksisterende program som du ikke har fuld kontrol
>over (oversætter), skal det laves som et DLL.
Ja, det er en udvidelse til programmet. Jeg har fået det til at virke
hvis jeg
lader background programmet loade dll'en og lave min form fra dll
koden.
Men da det giver en række problemer at køre min form inde i bakground
programmet (som dll) vil jeg gerne have det til at køre i sin egen
process.
Men jeg forstår ikke hvorfor background programmet håndterer min form
anderledes når den er lavet fra en stand alone? Kan background
programmet håndtere forms fra en anden process anderledes end dem som
er
lavet fra dens egen process? Hvordan kommer man evt. rundt om det
problem?
Det virker som om at background programmet sættes på pause når jeg
klikker på min form lavet fra standalone exe filen (derefter minimeres
det),
hvorimod hvis jeg klikker på formen fra dll'en kører det andet
program
videre i baggrunden.
Mvh. Rasmus
| |
Rasmus (07-06-2005)
| Kommentar Fra : Rasmus |
Dato : 07-06-05 23:08 |
|
Hej
Efter lidt videre undersøgelse:
>Two processes will each have their own memory space. One process may
>write to memory, but the other process is totally unable to see it.
>
>When the CPU switches between processes, it has to map out the entire
>address space for one process, and map in a new address space for the
>second.
Når jeg ligger min form on top, eller med ParentWindow til "background
programmet", vil der så ske det, når jeg klikker på min form, at den
skifter memory'en ud for henholdvis min pocess og background
programmets?
Background programmet vil altså ikke være den aktive process når man
trykker på min form?
Så vidt jeg ved, vil background programmet ikke "køre", altså sætte
sig selv og sine beregninger på pause, hvis det ikke er den aktive
process, og dermed minimeres (det kører som fullscreen).
Kan man ikke på en eller anden måde få backgroundprogrammet til at
forblive den aktive process? Eller "snyde" det til at tro at det er den
aktive process?
I BCB help skrives der om ParentWindow:
"...causes the control to be moved into the parent's screen area."
Dvs. at der skiftes mellem 2 processer når henholdsvis background
vinduet og mit vindue er aktivt?
På forhånd tak!
Mvh. Rasmus Steffensen
| |
Mogens Hansen (08-06-2005)
| Kommentar Fra : Mogens Hansen |
Dato : 08-06-05 16:00 |
|
> "Rasmus" <fsim@ofir.dk> wrote in message
> news:1118182058.049570.283820@g43g2000cwa.googlegroups.com...
Jeg fornemmede godt lidt begrebsforvirring.
Een process er eet kørende program, hvor der hører nogle resourcer til:
f.eks. hukommelse, vinduer.
Task Manager'en i Windows NT/2000/XP kan vise en liste over processer på
maskinen i fanebladet "Processes".
Een process man kan mange vinduer - men behøver ikke at have nogen.
Eet vindue hører altid til netop een process (og een tråd) - nemlig den der
oprettede vinduet.
En processn (og typisk een tråd i den process) eksekverer alt det arbejde
der hører til _alle_ vinduer som tilhører den process.
En process vil køre hvis den har noget at lave og operativsystemet giver den
lov - uanset om dets vinduer er synlige eller ej.
Højest eet vindue har _fokus_ - hvilket vil sige at det kan modtage
tastetryk. Dette vindue kan man godt kalde forgrundsvinduet.
> Efter lidt videre undersøgelse:
> >Two processes will each have their own memory space. One process may
> >write to memory, but the other process is totally unable to see it.
> >
> >When the CPU switches between processes, it has to map out the entire
> >address space for one process, and map in a new address space for the
> >second.
Een process har (stort set) kun adgang til sine egne resourcer - Windows
sikrer at en process ikke kan læse og skrive i en anden process hukommelse.
Når operativsystemet mapper hukommelse ud og ind i forbindelse med process
skifte, betyder det blot at det område bliver tilgængeligt for læsning og
skrivning ændres - ikke at hukommelsens indhold bliver ændret eller f.eks.
skrevet til disken
>
> Når jeg ligger min form on top, eller med ParentWindow til "background
> programmet", vil der så ske det, når jeg klikker på min form, at den
> skifter memory'en ud for henholdvis min pocess og background
> programmets?
Hvis din form er oprettet i en anden process en "background programmet", og
du sætter din forms ParentWindow til at være et vindue der findes i
"background programmet" så har jeg ingen anelse om hvad der sker.
Jeg vil anse det for at være et højest atypisk design.
Allerede hvis flere tråde i samme process begynder at eje vinduer bliver jeg
dybt bekymret over designet.
For at vende tilbage til noget af dit oprindelige spørgsmål, betyder det at
din form almindeligvis skal være oprettet af samme process som "background
programmet", hvilket igen betyder at den skal ligge i et DLL som bliver
kaldt fra "background programmet".
> Background programmet vil altså ikke være den aktive process når man
> trykker på min form?
Jo, det kan den sagtens være, idet flere processer sagtens kan være
eksekvere samtidig (logisk set - men også fysisk hvis det kører på en multi
CPU maskine eller på en CPU med HyperThreading)
> Så vidt jeg ved, vil background programmet ikke "køre", altså sætte
> sig selv og sine beregninger på pause, hvis det ikke er den aktive
> process, og dermed minimeres (det kører som fullscreen).
Det er forkert forstået.
> Kan man ikke på en eller anden måde få backgroundprogrammet til at
> forblive den aktive process? Eller "snyde" det til at tro at det er den
> aktive process?
Dit system skal formodentlig laves så det kun har een process.
> I BCB help skrives der om ParentWindow:
> "...causes the control to be moved into the parent's screen area."
> Dvs. at der skiftes mellem 2 processer når henholdsvis background
> vinduet og mit vindue er aktivt?
Det er kun et anliggende for vinduet, og har egentlig ikke noget med
processer at gøre.
Det område et child vindue kan tegne sig på er begrænset af parent vinduet
størrelse.
Venlig hilsen
Mogens Hansen
| |
|
|