>Hogy tudom megcsinalni, hogy irok Delphiben egy programot es nem akarom,
>hogy megjelenjen alol a toolbarban, vagyis hogy ne lehessen kilepni
>belole normalis modon!!!!! Legfentem az Ora, meg a billentyuzet mellett
>a jobb also sarokban, de ha lehet akkor csak a TASK MANAGERREL lassam.
>Nem tudnavalaki nekem erre gyorsan egy megoldast kuldeni!!!!
Az ablak eltuntetese a taskbarrol: ShowWindow(Application.Handle,SW_HIDE);
Azonban tray icon keszitesere gyors (3 soros) modszer nincs igazan... (Amugy
a Shell_NotifyIcon() kornyeken probalkozzal!)

>MEg ha lehet meg valami. Szeretnek Delphi programbol elinditani egy
>szalat egy iciri piciri prioritassal, ezert, hogy a progi ne foglalja le
>nagyon a rendszert. Hogy tudom ezt megcsinalni, milyen metodusokat kell
>felulirni es hogy. A szal azt kellene csinalja, hogy teszteli  az eltelt
>idot es ha lejart ujra bootol a gep, vagy ha lehet kiir valamit es
>utanna lefagyasztja a gepet.
>Meg lehet ezeket csinalni???
Uj szal inditasahoz egyszeruen letre kell hozni egy peldanyt egy TThread-bol
leszarmaztatott objektumbol. Persze a leszarmaztatott objektumban felul kell
irni (override) a thread Execute metodusat, ugyanis ez az ami a futas (az
szal "elete" soran) vegrehajtodik... Amikor ez befejezodik akkor a
thread-nek is vege - ez azt jelenti, hogy ennek a metodusnak teljesen
blokkolo jellegu (tehat nem mint egy esemeny-kezelo, ahol veges idon belul
_feltetlenul_ vissza kell adni a vezerlest, hogy ne alljon meg a teljes
alkalmazas).
A thread prioritasa annak Priority property-jenek (ki gondolta volna?;)
segitsegevel allithato.
Bovebb informaciot es peldakat a help-ben talalhatsz a dologrol...
Bar a gep lefagyasztasra valoszinuleg tobb modszer is letezik (pl. Windows
inditasa, betoltes utan eger mozgatasa, stb. ;), en ezzel nem igazan
probalkoznek, mert egyreszt nem igazan praktikus (pl. adatvesztes es tarsai
miatt) masreszt nem latom mi a teteje a dolognak...
A Windows-bol valo kilepesre pedig az ExitWindows() ill. ExitWindowsEx()
fuggvenyek hasznalhatok...
De megmondom az oszintet: nem ertem, hogy egy watchdognak (mert ugye ezt
akarsz csinalni, nem?), miert kellene kilepnie a Windows-bol, ha megall egy
progi???

Gabor

>> Csak egy megjegyzes: Ha jol emlexem, akkor a 80286-os nem volt teljesen
>> komptabilis a 8086-ossal. Ha minden igaz, akkor a stack-re
>> pakolgatasnal a masolas es a SP valtoztatasa mas sorrendben tortent...
>
>Ez azert durva lett volna, nem ott volt a kulonbseg. Volt valami
>hasonlo tenyleg, ha jol remlik, akkor egy exception-nel (talan div0)
>volt kulonbseg, hogy a push-olt IP az utasitasra, vagy az utasitas
>moge mutat-e.
Miert lenne durva a dolog? Szerintem nem ez lenne a legdurvabb
inkompatibilitasi problema az Intel torteneteben...
Az egeszben egyebkent az a szep, hogy tenyleg igaz az SP-s dolog - mar
megint csak az i386 doksijat tudom idezni:


"14.7  Differences From 8086
[...]
  4.  Value written by PUSH SP.

      The 80386 pushes a different value on the stack for PUSH SP than the
      8086/8088. The 80386 pushes the value of SP before SP is incremented
      as part of the push operation; the 8086/8088 pushes the value of SP
      after it is incremented. If the value pushed is important, replace
      PUSH SP instructions with the following three instructions:

      PUSH  BP
      MOV   BP, SP
      XCHG  BP, [BP]

      This code functions as the 8086/8088 PUSH SP instruction on the
80386."

Szoval - errol ennyit...

Azt hiszem fel fogom rakni valahova a webre es akkor szepen majd mindenki
elolvasgathatja mielott allandoan belekot a masikba - amikor az igazat
mond...

Amugy egyebkent a pluszban emlitett dolog is igaz:

"  2.  Divide Exceptions Point to the DIV instruction.

      Divide exceptions on the 80386 always leave the saved CS:IP value
      pointing to the instruction that failed. On the 8086/8088, the CS:IP
      value points to the next instruction."

Gabor

>>> Kulturaltabb nyelevekben meg ott van a strukturalt exception handling 
>>Lattad mar, hogy milyen ASM kod van mogotte? Valoszinuleg a programozo 
>>szamara kenyelmes megoldas, es biztosan attekinthetobb a forras... 
>Viszont a hibakezeleseket egy helyen el lehet intezni, nem kell minden hivas 
>utan a return code-ot elemezgetni, kiugrani, stb... 
>A mai gepeken az alkalmazasok 99%-anal ez nem okozhat gondot. 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Ezt mar nem birom....  pont az ilyen hozzaallas alazza verig azokat a
programozokat, akik hatekony progikat akarnak irni (sajnos ok vannak
kissebbsegben). A mai mentalitas az, hogy 5 perc alatt osszedobunk
valamit egy vizualis nyelven, ami annyit tud, hogy kirak egy ablakot meg egy
gombot. Az egesz 3 mega, es egy erogep kell neki....
Persze minek ilyen aprosagokkal torodni, hiszen a mai gepek legalabb
PII-esek, es minimum 128M ram van bennuk....
Ennek az egesznek a hardware gyartok orulnek a legjobban, mert a
szerencsetlen felhasznalonak meg kell vennie az erosebb gepet, hiaba
akar o csak teszem azt szoveget szerkeszteni...
Mi (akik programozonak nevezzuk magunkat) mi tehetunk arrol, hogy
mikozben a gepek teljesitmenye a csillagos egig no, addig a programok
hatekonysaga allando, sot azt is meg merem kockaztatni, hogy egyes
alkalmazasok teruleten csokken. Pedig csak egy kis odafigyeles es plusz
raforditott ido kellene. Tudom, hogy az utobbi a problemas, de errol is "mi"
tehetunk; ha a megrendelo latja, hogy 2 nap alatt is meg lehet csinalni azt,
ami kulonben 3 het lenne, nana hogy a 2 napot valasztja....
Bocs, ha hosszu voltam, de ezt ki kellett adnom magambol.

Visszaterve az eredeti temahoz,
a goto arra jo, hogy megkeverje a vizualis "fogd es vidd" modszerhez
szokottakat a feltetlen vezerlesatadas egyszerusegevel..... ;))))
A processzor nem hulye, nem tudja, hogy mi az a "strukturalt exception
handling", o csak annyit tud, hogy IGEN/NEM (nagyon sarkitva), ha ezt
szem elott tartanatok (akinek nem inge nem veszi magara), akkor nem
torne ki ilyen ostoba flame.....

--
JimBoo >
Suse 6.0 v2.2.7

sziasztok,

tud vki megoldast a kovetkezo problemara?

kliensek olvasnak/irnak egy megosztott objektumot. az utkozesek
elkeruleset lockolassal akarjuk megoldani, azaz, ha egy kliens
modositani akarja az objektumot, bejegyzi magat a szerveren, h most ove
az objektum, utana beolvassa az erteket, szuttyog rajta egy kicsit,
kitalalja az uj erteket, beirja, aztan torli a lockot a serveren. amig
az objektum lockolva van, masik kliens nem ferhet hozza.

namost. igen kellemetlen kovetkezmenyekkel jarhat, ha egy kliens, miutan
lockolta az objektumot, meghal/lefagy/vegtelen ciklusba
kerul/mittudomen, mindenesetre keptelenne valik a lock megszuntetesere.
ezt elvileg meg lehet oldani ugy, hogy a kliens, amig lockol, bizonyos
idokozonkent jelzi a szervernek, h meg el. csak ket problema van:

1. ha az objektumfeldolgozo ciklusban helyezzuk el a visszajelzo
utasitast, idonkent elofordulhat, h tul sokaig dolgozgat, es igy nem tud
idoben visszajelezni, a szerver pedig ezt ugy ertelmezi, h a kliens
meghalt.

2. ha kulon threadben tortenik az idonkenti visszajelzes, lehet, h a
kliensalkalmazas ugy hal le, h a visszajelzo thread beragad, es tovabb
kuldozgeti az eletjeleket. ez tenyleg elofordul, nalunk is tortent mar
ilyen.

szoval, vannak-e jobb modszerek a lock befagyasanak elkerulesere?
esetleg tudna-e vmelyikotok ajanlani olyan weboldalt v konyvet v barmit,
ami a lockolas kerdesenek ilyes megkozelitesevel foglalkozik? vagy
esetleg barmilyen otlet, h milyen kulcsszavakra erdemes keresni a weben,
h ilyen megoldasokat talaljak?

az esetleges otleteket legyetek kedvesek maganmailben is, mert eleg
surgos volna.
koszi, elore is.

weisz balint ]

On 10 Dec 99 at 17:55, Sting > wrote:

> > > Ha minden igaz, akkor a stack-re pakolgatasnal a masolas es a
> > > SP valtoztatasa mas sorrendben tortent...
> >
> > Ez azert durva lett volna, nem ott volt a kulonbseg. Volt valami
 ...
> Miert lenne durva a dolog? Szerintem nem ez lenne a legdurvabb
> inkompatibilitasi problema az Intel torteneteben...
 ...
>   4.  Value written by PUSH SP.
 ...
> Szoval - errol ennyit...

Eloszor is bocs, a push sp-t tenyleg elfelejtettem.

Viszont az, hogy *altalanosan* a stack-re pakolgatasnal maskor
valtoztatna az SP-t, az ha jobban belegondolsz, *nagyon* durva lenne.
Egyetlen korabbi stack frame-es szubrutin (push bp + mov bp,sp) se
mukodne...

> Azt hiszem fel fogom rakni valahova a webre es akkor szepen majd
> mindenki elolvasgathatja mielott allandoan belekot a masikba -
> amikor az igazat mond...

Hmmm, azert azt nem gondolom, hogy "allandoan" oktalanul kotok bele
a masikba.

István
--  Istvan Marosi  --  http://www.sch.bme.hu/~marosi  --
--  Recosoft Ltd.  --  mailto:  --