System Tray-es alkalmazás problémája
2003-09-10T13:58:23+02:00
2003-09-23T12:48:57+02:00
2022-06-29T10:00:23+02:00
  • És mi van akkor, ha használjuk a GetSystemMetrics(SM_CXSCREEN) eljárást és figyeljük a WM_DISPLAYCHANGE üzenetet? Akkor jó, nem?
    Mellesleg jónak tűnik ez a 0,0 méretű ablak is. Kérdés, hogy nem zavarja-e meg a winfost. Konkrétabban az a lényeg, hogy hogyan műxik a winfos. Ha ott vagyok az egérrel a "láthatatlan" ablak bal-felső sarkában, nézi-e, hogy az ablakméret 0?
    Persze ilyen bug biztosan nincs benne (?)
    Mutasd a teljes hozzászólást!
  • Hmm, vertikálisan is lehet több monitor? Azt hittem, csak horizontálisan.
    Mutasd a teljes hozzászólást!
  • Sajnow lehet, hogy még ez is megjelenik: többmonitoros konfiguráció esetén az origó a promer monitor bal felső sarkában van. Ha ez nem a legbaloldalibb monitor, akkor a negatív koordináták is értelmezettek :)
    Mutasd a teljes hozzászólást!
  • Nem tudom valaki bogarászott-e már a WinSight vagy Spy++ programokban. Abból tanulságképpen kivehető, hogy másik jó megoldás a

    BorderStyle:=bsNone; Width:=0; Height:=0;

    is.
    Mutasd a teljes hozzászólást!
  • Left:=-Width-5; Top:=-Height-5;

    Nincs az a felbontás, ami ezt megjelenítené.
    Mutasd a teljes hozzászólást!
  • Mit értesz az alatt, hogy a képernyőn kívülre rakod az ablakot?

    x:=2000, y:=165343 ????

    Mert mi van akkor, ha a muksónak ilyen felbontású monitora lesz, vagy, ha több videókártyával és monitorral telerakja a fél szobát? Elképzelhető, hogy valahol felbukkan a "Képernyőn kívüli" ablakod és ez elég blama....

    A többi világos
    Mutasd a teljes hozzászólást!
  • Hehe... oké, mexűnt, csak még annyit, hogy a programnak nem kell mindenáron kilépnie, ha a főablakát bezárják. (msdev, mfc app.)
    Mutasd a teljes hozzászólást!
  • Köszi mindenkinek!
    A probléma mgszűnt a
    SetForegroundWindow(Application.Handle);
    Application.ProcessMessages;
    hatására!
    Mindenkinek köszönöm.
    Mutasd a teljes hozzászólást!
  • Köszönöm a sok infót!
    Környezet: Delphi 7
    ha megírod az email címed, akkor elküldöm a forrást és mazsolázhatsz rajta.
    (szemisun@freemail.hu)
    Mutasd a teljes hozzászólást!
  • hozzuk előre és rakjuk képernyőn kívülre a főablakot


    Látom ez félreérthető. A főablak alatt nem azt az ablakot értettem, amin a user dolgozik, ez utóbbi nem is lehet a főablak, mert akkor ha ezt bezárná a user, akkor simán kilépne a program, és nem értené, hogy miért tünt el a tray icon.

    Tehát a MainForm-nak nem szabad annak az ablaknak lenni, amin a user dolgozik. Azt hiszem ez félreérthető volt.

    Egyébként az Application.Handle pont ilyen ablak, részlet a Delphi5 Forms.pas TApplication.CreateHandle eljárásából:


    procedure TApplication.CreateHandle; var TempClass: TWndClass; SysMenu: HMenu; begin if not FHandleCreated and not IsConsole then begin FObjectInstance := MakeObjectInstance(WndProc); if not GetClassInfo(HInstance, WindowClass.lpszClassName, TempClass) then begin WindowClass.hInstance := HInstance; if Windows.RegisterClass(WindowClass) = 0 then raise EOutOfResources.Create(SWindowClass); end; FHandle := CreateWindow(WindowClass.lpszClassName, PChar(FTitle), WS_POPUP or WS_CAPTION or WS_CLIPSIBLINGS or WS_SYSMENU or WS_MINIMIZEBOX, GetSystemMetrics(SM_CXSCREEN) div 2, GetSystemMetrics(SM_CYSCREEN) div 2, 0, 0, 0, 0, HInstance, nil); FTitle := ''; FHandleCreated := True; SetWindowLong(FHandle, GWL_WNDPROC, Longint(FObjectInstance)); if NewStyleControls then begin SendMessage(FHandle, WM_SETICON, 1, GetIconHandle); SetClassLong(FHandle, GCL_HICON, GetIconHandle); end; SysMenu := GetSystemMenu(FHandle, False); DeleteMenu(SysMenu, SC_MAXIMIZE, MF_BYCOMMAND); DeleteMenu(SysMenu, SC_SIZE, MF_BYCOMMAND); if NewStyleControls then DeleteMenu(SysMenu, SC_MOVE, MF_BYCOMMAND); end; end;

    Jó megoldás ez is, de gyakorlatilag ekvivalens az enyémmel.
    Mutasd a teljes hozzászólást!
  • 1. Talán elegánsabb megoldás a "hozzuk előre és rakjuk képernyőn kívülre a főablakot" módszernél egy üres ablak létrehozása, ami amúgíis "odakint" van, de még ettől is idegenkedek.

    2. Csak benyögöm, nem akarok lin vs win vitát indítani, de a windowmaker-nek van egy elég jó menürendszere, amit (ami-szerűt) szerintem m$-éknek sem ártana hozni.

    3. Az az emlegetett "feature" szerintem az, hogy a régebbi win-ekben nekem _nagyon_ idegesítő volt, hogy ha bejön egy ablak, akkor az aktív menüm eltűnik (és ez gáz, amikor a 33. almenüben vagyok). Erre találták ki azt, hogy ne tűnjön el minden vicikvacak eseményre a menü. (Bár lehetne még fejleszteni rajta pontosan a topic problémája miatt (hiszen szerintem ez elvi hiba), meg azért is, mert ha a start menüből mondjuk törölni akarok egy menüt, aminek van jó sok almenüje, akkor bejön a törlés ablak, és a start menü eltűnik. Jó lenne, ha nem így lenne.) Hol írhatom ezt meg a m$-nek?
    Mutasd a teljes hozzászólást!
  • Én is épp egy ilyet találtam, az Iczelion's masm32 tutoriálok között.

    When the popup menu is displayed, if you click anywhere outside the menu, the popup menu will not disappear immediately as it should be. This behavior occurs because the window that will receive the notifications from the popup menu MUST be the foreground window. Just call SetForegroundWindow will correct it.
    After calling SetForegroundWindow, you will find that the first time the popup menu is displayed, it works ok but on the subsequent times, the popup menu will show up and close immediately. This behavior is "intentional", to quote from MSDN. The task switch to the program that is the owner of the tray icon in the near future is necessary. You can force this task switch by posting any message to the window of the program. Just use PostMessage, not SendMessage!


    bővebben:
    Iczelion's tut

    itt a tutorials-ok között és asszem 23-as
    Mutasd a teljes hozzászólást!
  • mert így kell kirakni a menüt:

    GetCursorPos(pt);
    SetForegroundWindow(Application.Handle);
    Application.ProcessMessages;
    pmenMenu.Popup(pt.x, pt.y);

    Vagyis a kirakás előtt egy SetForegroundWindow és egy Application.ProcessMessages kell.

    d5
    Mutasd a teljes hozzászólást!
  • csak éppen amikor közben előbukkan egy újabb ablak (vagy más módon a z-rend tetejére kerül egy ablak miközben nyitva van a menü), akkor a menü ottmarad, és nem lehet eltüntetni, csak ha kiválaszt egy pontot belőle az ember. Erről beszéltem, hogy feature (nem trayikon, hanem popup menü feature, az egész Windows-ban), és nyilván a kolléga is ezt ecsetelte


    vs.

    ha megnyitom a menüt és úgy döntök,
    hogy mégsem választok ki belőle semmit és a menün kívűl kattintok valahova


    netchan
    Mutasd a teljes hozzászólást!
  • A feature az, hogy ha egy menü megjelenítésekor az az alkalmazás aktív, amelyik megnyitotta azt a menüt, akkor az alkalmazás fókuszvesztése esetén a menü eltűnik.

    1. Ha az alkalmazás nem aktív és úgy dob fel egy menüt, akkor az a menü nem is fog eltűnni. Márpedig a kollégának ez a baja.

    2. Ha az alkalmazást úgy aktiválom, hogy az end-user által nem látható ablakra adom a focust és csak ezután dobok fel context menüt, akkor a menü az alkalmazás focus vesztésekor el fog tűnni.

    Ez mindenre magyarázat.
    Mutasd a teljes hozzászólást!
  • Mindegyik menü eltűnik.

    Normál körülmények között igen, csak éppen amikor közben előbukkan egy újabb ablak (vagy más módon a z-rend tetejére kerül egy ablak miközben nyitva van a menü), akkor a menü ottmarad, és nem lehet eltüntetni, csak ha kiválaszt egy pontot belőle az ember. Erről beszéltem, hogy feature (nem trayikon, hanem popup menü feature, az egész Windows-ban), és nyilván a kolléga is ezt ecsetelte - azt ugyanis nehezen hiszem el, hogy egy tök normál helyzetben (amiről te is írsz) ottmaradt volna neki a menü.
    Mutasd a teljes hozzászólást!
  • Visszakérdezek: miért van trayikon és miért arra kattint a felhasználó ha az alkalmazásablakkal akar dolgozni és az mindig előtérbe jön amint a trayikonra kattint?


    Itt a félreértes! Azt nem mondtam, hogy bármilyen ablaknak látszódnia kell a végfelhasználó számára.

    Kéretik a személyeskedés mellőzése, segíteni szándékszom.
    Mutasd a teljes hozzászólást!
  • Szerintem semmilyen galibát nem okoz az, hogy ha a felhasználó amúgy is azzal a programmal akar foglalkozni, amely alkalmazás ikonjára kattintott, nos az magához veszi a focus-t. Mi másért kattintott rá akkor a felhsználó?

    Visszakérdezek: miért van trayikon és miért arra kattint a felhasználó ha az alkalmazásablakkal akar dolgozni és az mindig előtérbe jön amint a trayikonra kattint?

    Én biztos agygörcsöt kapnék ha a trayikonhoz kapcsolód alkalmazás már csak a menü előhívásakor is előugrana, de szerintem így lenne másik néhány százmillió Windows-használó társam is. És talán nem véletlen, hogy egyetlen program sem így működik (esetleg az általad gyártottak kivételével).

    Egyébként is a System tray-re kattintás eleve elveszi a focus-t az éppen aktív alkalmazástól.

    Igen, csak éppen a taskbar veszi el a fókusz, ami egyrészt eleve látható és legfölül van (legalábbis a kattintást pillanatában), másrészt nem rendezi át a képernyőt, az ablakok struktúráját. Ehhez képest ha egy alkalmazásablak ugrik az előtérbe, az elég durván átrendezi a desktopot, és tök feleslegessé teszi a trayikon menüt (hiszen ha elöl van az alkalmazás, akkor már abban is ki lehet választani a funkciót, nemde?)
    Mutasd a teljes hozzászólást!
  • Ez legjobb tudomásom szerint "feature"


    Kattints bármelyik icon-ra a system tray-en, majd máshova, ne a megjelenő menüre.

    Mindegyik menü eltűnik.

    A kérdés felvetése sem lehetett véletlen.
    Mutasd a teljes hozzászólást!
  • A lényeg még az, hogy az ilyen típusú alkalmazások MainForm-ja rejtett kell legyen. Amikor valaki a tray iconra kattint ezt a rejtett ablakot újra láthatóvá kell tenni, de úgy, hogy annak pozíciója kívűl legyen a látható desktopon. Ekkor ez az ablak aktiválható, de a felhasználó semmit nem lát ebből a trükkből, a menü megjeleníthető. A menü eltűnésekor pedig újra rejteni kell a fő ablakot, hogy az Alt+Tab szekvenciában ne látszódjon. Ezer ilyet csináltam már, és mások is így csinálják.
    Mutasd a teljes hozzászólást!
  • Az alkalmazás csak a menü megjelenése idejéig lesz aktív, mihelyst máshova kattint a felhasználó, az alkalmazás elveszíti a focust.

    Szerintem semmilyen galibát nem okoz az, hogy ha a felhasználó amúgy is azzal a programmal akar foglalkozni, amely alkalmazás ikonjára kattintott, nos az magához veszi a focus-t. Mi másért kattintott rá akkor a felhsználó?

    Egyébként is a System tray-re kattintás eleve elveszi a focus-t az éppen aktív alkalmazástól.
    Mutasd a teljes hozzászólást!
  • A trayikonnak általában pont az a lényege, hogy olyan alkalmazáshoz kapcsolódik, amelyik az idő nagy részében nem látható, ergo, nem is fókuszálható. Meg szép is lenne mindjárt fókuszálná magát az alkalmazás amint a trayikonjára kattint valaki (akkor mi értelme a trayikonnak?).
    Mutasd a teljes hozzászólást!
  • A lényeg az, hogy mielőtt a menü megjelenne, az alkalmazásodnak aktívnak kell lennie, azaz a focus-nak az alkalmazás valamelyik ablakán kell lennie. Ekkor ugyanis ha az ikon mellé kattintasz, az alkalmazásod elveszíti a focus-t és a popup menü is el fog tűnni.

    Ha konkrétabb válasz kell, írd meg milyen fejlesztőkörnyezetben dolgozol.
    Mutasd a teljes hozzászólást!
  • Ez legjobb tudomásom szerint "feature", tehát minden alkalmazásnál így működik, nem te szúrod el. Oka valószínűleg az Explorer.exe speciális jellegéből adódik - de biztosat erről nem tudok.
    Mutasd a teljes hozzászólást!
  • Üdv mindenkinek!
    A gondom az volna, hogy van egy system tray-es alkalmazásom!
    Ha a progit lekicsinyítem akkor gy ikont rakok az óra mellé és az ikonhoz egy PopUp menüt adok. Lekicsinyítés után az ikon megjelenik, a popup hozzárendelődik, minden menüpont királyul működik, DE
    ha megnyitom a menüt és úgy döntök, hogy mégsem választok ki belőle semmit és a menün kívűl kattintok valahova,
    akkor NEM ZÁRÓDIK be! Miért? Előre is köszönöm a probléma megoldójának!
    Mutasd a teljes hozzászólást!
abcd