Table of Contents

GUI

hnizdo

  1. clear se nevraci do puvodniho stavu, to je dobre? asi neni dobre, aby se stav jednoho tlacitka vracel do normalu pri stisku druheho, po stornu toho file vyberoveho dialogu vybublaji na pozadi nejake vyjimky.
  2. K cemu je v obsluze toho FileChooseru ten string buffer, kdyz se vraci ten string, a btw, ten string se vraci i kdyz se nevybere nic, to mozna zpusobuje tu vyjimku.

meister

  1. prepocitavani velikosti obrazku nejak moc dobre nefunguje
  2. set visible je dobre dat az po vytvoreni layoutu, jinak se nic nevykresli nebo je nutno rucne volat repaint()
  3. otevirat soubor jako je JPEG pri kazdem repaintu je barbarstvi. Doby, kdy kazdemu stacilo 640kB pameti davno minuly, takze bylo lepsi nacist ten obrazek do pameti jednou.

burdova

  1. no, jeste tam mohlo byt neco na kliknuti
  2. pro udalosti, kdyz uz nepouzivate action listener, se hodi spis mouseclicked, je prirozenejsi, ze to zacne reagovat az po uvolneni mysi

herna

  1. proc se prohazuji labely clear a open?
  2. ty udalosti mate nejake splasene, zvyraznuji se oba buttony najednou.
  3. resize nefunguje na oba rozmery,
  4. clear se projevi az pri prvnim prekresleni, je lepsi zavolat repaint
  5. za ty nazvy metod pro obsluhu mysi by vas kolegove nemeli radi
  6. kdyz jsem psal fantazii se meze nekladou, nemyslel jsem na ukor pouzitelnosti

jelinek

  1. pekna fotka ;-)
  2. asi bude lepsi pouzit mouseEntered v mouseListeneru, ten mouseMoved imho vygeneruje hromadu zbytecnych eventu
  3. cteni obrazku pri kazdem repaintu je dost narocne, lepsi je to natahnout do pameti jednou
  4. na udalosti spis mouseClicked nebo action listener, mouseREleased by se mohlo zvrhnout, mozna

krausova

  1. hm, prvni nativni dialog, mate plus !
  2. nejdriv jsem vas podezrival ze nacitate soubor pri kazdem repaintu, ale asi to je tou zvolenou kvalitou skalovani

linduska

  1. tlacitka se nevraci do puvodniho vzhledu pri opusteni, chybi reakce na kliknuti
  2. jen BMP? takovy obrazek snad ani nikdo uz nema
  3. ty tlacitka bude asi lepsi vykreslit nejprve pozadi, a pak okraj
  4. pri uzavreni okna se neukonci aplikace!

prasltom

  1. ok

rodina

  1. ten resize se chova v nekterych krajnich pripadech divne
  2. nejaka zmena vzhledu tlacitek?
  3. neukonci se aplikace pri uzavreni okna?

sebek

  1. nejaky divny pomer maji otevirane obrazky
  2. kdyz kliknu na clear, odbarvi se tlacitko open?
  3. stejny kod jako pan hnizdo

skorpil

  1. kdyz stornuju open dialog, predchozi obrazek se smaze :/

Pozdní odevzdání

kratina

  1. zadne zmeny vzhledu nad tlacitky (pri prejeti mysi, kliknuti),
  2. resize moc dobre nefunguje
  3. aplikace se po zavreni okna neukonci !?

muska

  1. ok,
  2. ta odezva na kliknuti - lepsi jsou pressed a released eventy

reiter

  1. pokud poprve open dialog stornuju, v pozadi vyskoci exception
  2. u toho vykresleni mate duplicity v kodu, treba text tlacitka vypisujete pokazde stejne
  3. ta odezva na kliknuti - lepsi jsou pressed a released eventy

tesar

  1. setVisible(true) je vhodne umistit az na konec designu, ono se to pak jinak nemusi prekreslit
  2. mozna jeste nejaka zmena vzhledu pri kliknuti
  3. resize moc dobre nefunguje

turek

  1. resize moc dobre nefunguje
  2. nezjistil jsem proc, ale cpu mi vyskoci na 100%, a spadne az pri smazani obrazku

Thready

felcmma

  1. docela jste si to zjednodusil. V zadani jsem tusim mluvil o mnozine producentu a mnozine konzumentu a o fronte. A to je na tom problemu dost podstatne.

fuchsova

  1. popravde, netusim, jakto ze vam to funguje, ale nepodarilo se mi to rozbit

helankar

  1. obcas deadlock
  2. to vase reseni pro oznameni cekatelum vzdy probudi vsechny, i kdyz je prace jen pro jednoho, takze se tam zbytecne pracuje navic (ruzne testy)

hykajan

  1. to notifyAll, kdyz je treba jen prvek ke zpracovani, zbytecne probouzi vsechny
  2. wait s maximalnim cekanim - ano, muze to zabranit deadlocku, ale zas pracuji naprazdno …

kodera

  1. ok, blocking queue jsem nezakazal :/
  2. ale omezenim nekterych promennych jste si to zjednodusil (jiny pocet producentu, kazdy vyrobi jiny pocet polozek, atd.)
  3. a co kdyz je nektery konzument rychlejsi, to se pak bude cekat na ty pomalejsi, nebo je lepsi jim pomoct?

makaric

  1. obcas deadlock

mostek

  1. podedeni linked listu :/
  2. trochu jsem posteloval konstanty a deadlocklo to
  3. while(fronta.getSize()>0){} - no to snad ne!, navic, fronta se muze vyprazdnit i behem vypoctu - staci, aby byli producenti pomalejsi.
  4. konzument tam v pripade ze je prazdna fronta, nespi, ale porad se tam toci (i kdyz je pravda, ze vetsinu casu spi)
pjvomo/ukol3.txt · Last modified: 2011/08/16 22:33 (external edit)
Back to top
Driven by DokuWiki Recent changes RSS feed Valid CSS Valid XHTML 1.0