| Kirjoittaja |
Viesti |
    
jap
| | Keskiviikkona, 10. elokuuta, 2005 - klo 19.16: | |
Olen tehnyt ohjelman, joka kuuntelee kahta viestiporttia. Toinen porteista on ohjelman ikkunan viestiportti, johon tulee IDCMP-viestejä, ja toinen on kontrolliportti, johon tulee viestejä toiselta prosessilta. Kontrolliporttiin tulee viestejä, joilla pyydetään ohjelmaa näyttämään/päivittämään käyttöliittymässä näkyviä tietoja (tekstikenttien päivitystä ja ikkunaan kirjoittamista).
Ongelmana on ikkunan viestiportin lukkiutuminen. Ohjelma lakkaa reagoimasta kokonaan käyttöliittymässä olevien nappien painamiseen, kun kontrolliporttiin tulee nopeasti peräkkäin useita päivityspyyntöjä. Vaikka ikkunan viestiportti menee lukkoon, ohjelma jatkaa toimintaa normaalisti: se suorittaa kaikki kontrolliporttiin tulevat päivityspyynnöt.
Aina kun ikkunan porttiin tai kontrolliporttiin tulee viesti, ohjelma tyhjentää portin GetMsg-funktiolla while-silmukassa, vastailee samalla viesteihin ja suorittaa pyydetyt päivitykset.
En ymmärrä miksi Intuition lakkaa lähettämästä nappuloiden klikkauksia ohjelmalle. Eihän tuon toisen portin toiminta pitäisi vaikuttaa millään tavalla Intuitioniin?
Kaikki muut koneessa pyörivät ohjelmat jatkavat toimintaansa normaallisti, kun tuon oman ohjelman portti menee jumiin.
Niin ja ikkunan viestiportin mykistymistä ei tapahdu, jos kontrolliporttiin tulee harvakseltaan viestejä.
|
itix
| | Keskiviikkona, 10. elokuuta, 2005 - klo 22.07: | |
"En ymmärrä miksi Intuition lakkaa lähettämästä nappuloiden klikkauksia ohjelmalle."
Intuition ei koskaan lopeta. Ehkä oma ohjelmasi lopettaa vahingossa IDCMP:n kuuntelun? Muuta yksinkertaista selitystä en keksi.
|
jap
| | Keskiviikkona, 10. elokuuta, 2005 - klo 23.30: | |
Odottelen viestejä porteista tällä tavalla:
ulSignals = Wait(ulIntuitionSignal | ulGuiRefreshSignal);
ulIntuitionSignal ja ulGuiRefreshSignal määritellään ohjelman alussa, ennen kuin portteja aletaan kuunnella. (Otan arvot porttien MsgPort-tietueiden mp_SigBit-kentistä.)
Jos ulIntuitionSignal-muuttujan arvo muuttuu pääsilmukan sisällä tai jostain kumman syystä ikkunan viestiportin mp_SigBit-kentän arvo muuttuu kesken kaiken, niin se voisi selittää oudon käyttäytymisen. Pitääpä debugata noita...
|
itix
| | Torstaina, 11. elokuuta, 2005 - klo 0.08: | |
Signaalibitti voi muuttua ainoastaan jos suljet ikkunan tai kutsut ModifyIDCMP() funktiota sopivilla parametreilla.
|
jap
| | Torstaina, 11. elokuuta, 2005 - klo 4.29: | |
ulIntuitionSignalin arvo pysyi muuttumattomana koko ajan samoin kuin viestiportin signaalibitit.
Onko sillä mitään väliä miten pitkän ajan kuluttua vastaa IDCMP-viestiin? Käsittääkseni Intuition lakkaa lähettämästä IntuiTicks-viestejä jos niihin ei vastaa tarpeeksi nopeasti. Voisiko sama tapahtua GadgetUp yms. viestien kanssa?
|
Piru
| | Torstaina, 11. elokuuta, 2005 - klo 11.08: | |
Jos päivitysviestejä tulee iso määrä ja ohjelma pyörii pitkään GetMsg-loopissa käsitellen päivitysviestejä, voi intuition todella lakata lähettämästä viestejä (Tosin lähetys pitäisi käynnistyä uudeleen kun jonoutuneet IDCMP-viestit on käsitelty).
Jos kunkin päivitysviestin käsittely vie paljon aikaa, on ehkä syytä käsitellä mahdollisia IDCMP-viestejä tämän GetMsg-loopin sisällä (uusi GetMsg-looppi toisen sisällä).
HUOM: Jos päivitysviestien käsittely ei vie pitkää aikaa, ongelmia ei pitäisi olla! Tällöin vika on todennäköisesti itse ohjelmassa.
PS. Käyttääkö ohjelma gadtoolsia? Jos käyttää, muistithan käyttää GT_-alkuisia funktioita viestien käsittelyyn?
Jos mikään muu ei auta, niin joko päivitysviestien tai GUI:n käsittely voidaan erottaa omaan prosessiinsa.
|
jap
| | Torstaina, 11. elokuuta, 2005 - klo 23.21: | |
Päivitysviesteillä voidaan pyytää muutamien merkkijonokenttien sisällön päivittämisen ja jonkin ennalta määritellyn tekstin kirjoittamisen lisäksi pienen grafiikkaleikkeen kopioimista ikkunaan. IDCMP-viestit lakkaavat tulemasta, kun 2. ohjelma lähettää putkeen kaikki nuo viestit. Päivitysoperaatiot ovat suht. keveitä. Grafiikkaleikkeen takana on pikkuisen laskentaa, mutta ei mitään raskasta. Tekstikentissä näytetään muistissa valmiiksi olevia arvoja.
Käyttöliittymässä olevat napit ja merkkijonokentät ovat Boopsi-nappuloita. NewObject ei suostunut luomaan buttongclass-tyyppisiä nappuloita, mutta ulkoisella button.gadget-luokalla nappula syntyy. Olisin kyllä mieluummin käyttänyt buttongclassia  Merkkijonokentät ovat strgclass-olioita.
Kokeilin sellaista, että lähetän 2. ohjelmalle jonkin ajan kuluttua viestin, että menee pause-tilaan (lopettaa päivitysviestien lähetyksen). Ei auttanut. IDCMP-viestejä ei enää tule.
Kokeilen seuraavaksi ehdottamaasi sisäkkäisiä looppeja.
|
jap
| | Lauantaina, 13. elokuuta, 2005 - klo 19.17: | |
Ei ollut apua sisäkkäisistä loopeista
|
Jon
| | Lauantaina, 13. elokuuta, 2005 - klo 19.31: | |
Saadaanko me nähdä koodia?-)
|
jap
| | Sunnuntaina, 14. elokuuta, 2005 - klo 7.35: | |
Ette saa  Koodia on sen verran paljon, että sitä ei voi kopioida tänne.
Näyttäisi siltä, että käyttöliittymän päivitysrutiineissa tai 2. ohjelmassa on bugi, joka aiheuttaa ongelman. Jos tietäisi minkälaiset jutut voivat aiheuttaa IDCMP-viestien loppumisen (muu kuin pitkä viive viestiin vastaamisessa), niin virheen löytäminen olisi vähän helpompaa.
|
jap
| | Tiistaina, 16. elokuuta, 2005 - klo 8.31: | |
Ongelma ratkesi! 
Ohjelmat on tehty C++:lla ja varasin muistia kontrolliporttiin lähetettävälle viestille new:llä. Viestin piti olla public-tyyppisessä muistissa ja new ei sellaista muistia varannut. Nyt kun varaan muistia AllocMem:llä (public-muistia), IDCMP-viestien yhtäkkistä loppumista ei enää tapahdu.
Grafiikkaleikkeen kopioimisessa on vielä jotain hämärää, koska kone alkoi hyytymään siitä, mutta eiköhän sekin bugi löydy.
|
itix
| | Tiistaina, 16. elokuuta, 2005 - klo 11.43: | |
"Ohjelmat on tehty C++:lla ja varasin muistia kontrolliporttiin lähetettävälle viestille new:llä. Viestin piti olla public-tyyppisessä muistissa ja new ei sellaista muistia varannut. Nyt kun varaan muistia AllocMem:llä (public-muistia), IDCMP-viestien yhtäkkistä loppumista ei enää tapahdu."
MEMF_PUBLIC lipulla ei ole mitään merkitystä.
|
jap
| | Torstaina, 18. elokuuta, 2005 - klo 5.13: | |
itix: MEMF_PUBLIC lipulla ei ole mitään merkitystä.
No, AllocMemin käyttö näytti kuitenkin auttavan.
|
|