On 9 Lut, 20:03, "Lelek@" <n...@n...pl> wrote:
> to mi wyglada na jak cholern optymalizacj garbage collecrion czy co
> takiego w czasie wykonywania, e nie je eli buf = zamiana zawarto co pola
> wide char w UTF16 na UTF8 na bajty daje tylko null to tablica nie powstaje

To zabezpieczenie nie ma sensu, gdy len == 0 pętla się po prostu nie
wykona. A jaki wyjątek rzuca?

do góry

On 9 Lut, 20:14, "Lelek@" <n...@n...pl> wrote:
> nie będzie miało czego czytać w polu bo nic w nie nie wpiszę
>
> to byte Y = buf[0} czy int Y = (int)buf[0]
>
> zamyka program "przysłowiowy ble screen" i do widzenia
> zamyka aplikację

A może problem wynika z tego, że jak nic nie wpiszesz to dostajesz
null, na rzecz którego próbujesz wywołać jakieś metody? Już buf.length
może być problematyczne. Wtedy potrzebny byłby test na null i tyle.

do góry

W dniu 09.02.2011 19:59, Lelek@ pisze:
> Jeżeli w polu EditText nic nie wpiszę, będzie puste to próba odczytania
> buf[0] skończy się wywałką.
Chyba trochę namieszałeś:
> byte buf[] = new byte[256];
Tworzysz nową tablicę typu byte. Powinna być czytelna w odróżnieniu od
tablicy Byte w której trzeba dodatkowo utworzyć każdy element.

> int bfx[] = new int[256];
> int i, len;
>
> buf = FromEditText.getBytes("UTF-8");
Tutaj stary buf zostaje oddany do dyspozycji gc a przypisywany jest
nowy. Strzelam, że jak EditText jest pusty to zwraca null a nie pustego
stringa i stąd problem.

--
Pozdrawiam
Michoo

do góry

"ohouapss" <k...@g...com> wrote in message
news:5fa375b4-b868-4c45-82d9-ab166c0c6676@s28g2000pr
b.googlegroups.com...
On 9 Lut, 20:14, "Lelek@" <n...@n...pl> wrote:
> nie będzie miało czego czytać w polu bo nic w nie nie wpiszę
>
> to byte Y = buf[0} czy int Y = (int)buf[0]
>
> zamyka program "przysłowiowy ble screen" i do widzenia
> zamyka aplikację

//A może problem wynika z tego, że jak nic nie wpiszesz to dostajesz
//null, na rzecz którego próbujesz wywołać jakieś metody? Już buf.length
//może być problematyczne. Wtedy potrzebny byłby test na null i tyle.

wywalenie buf.length z kodu zakomentowanie go nic nie daje

do góry

"ohouapss" <k...@g...com> wrote in message
news:7e95f46b-b448-41f1-873e-676287a3a836@t8g2000vbd
.googlegroups.com...

// To zabezpieczenie nie ma sensu, gdy len == 0 pętla się po prostu nie
// wykona. A jaki wyjątek rzuca?

Nie wiem jak to sprawdzić, bo dopiero od tygodnia to robię :-) Nie wiem
gdzie tam sa debugery, ktore coś pokazują :-)
Podpowiedz mi :-)

Co do petli for(;;;) to może jej nie być. Chodzi o to, że jak długość jest 0
len=0 to nie wolno mi czytać buf[] bo aplikacja się zamyka bez powodu :-)
Jestem zdumiony tym zachowaniem.
W ogóle jestem zdumiony, że nie ma UNSIGNED w całej tej javie i wszystko co
sie chce robić trzeba robić na wiekszych, szczególnie boli uINT że trzeba go
obrabiać w LONG i stale maskować & 0xFFFFFFFFL

do góry

"Michoo" <m...@v...pl> wrote in message
news:iiuqum$k3b$1@news.onet.pl...

> > int bfx[] = new int[256];
> > int i, len;
> >
> > buf = FromEditText.getBytes("UTF-8");
> Tutaj stary buf zostaje oddany do dyspozycji gc a przypisywany jest nowy.
> Strzelam, że jak EditText jest pusty to zwraca null a nie pustego stringa
> i stąd problem.

Ja to wiem i ty to wiesz ale czemu oddaje pamięć przed końcem funkcji? tfu
metody i to jeszcze "likely" :-)

do góry

"Michoo" <m...@v...pl> wrote in message
news:iiuqum$k3b$1@news.onet.pl...
>W dniu 09.02.2011 19:59, Lelek@ pisze:
>> Jeżeli w polu EditText nic nie wpiszę, będzie puste to próba odczytania
>> buf[0] skończy się wywałką.
> Chyba trochę namieszałeś:
> > byte buf[] = new byte[256];

Ktoś na pl.comp.programming zapodał żeby zadeklarować ten buf[] jako final
hmmm. Czyżby w javie można tym zakazać wtrącać się w tę tablicę ? To i ma w
pewnym stopniu sens. Zaraz sprawdzę :-)

do góry

On Wed, 9 Feb 2011 21:35:20 +0100, Lelek@ wrote:
>"Michoo" <m...@v...pl> wrote in message
>> > buf = FromEditText.getBytes("UTF-8");
>> Tutaj stary buf zostaje oddany do dyspozycji gc a przypisywany jest nowy.
>> Strzelam, że jak EditText jest pusty to zwraca null a nie pustego stringa
>> i stąd problem.
>
>Ja to wiem i ty to wiesz ale czemu oddaje pamięć przed końcem funkcji? tfu
>metody i to jeszcze "likely" :-)

Przed koncem ? Raczej powinna przed poczatkiem - jak rozumiem to
getBytes alokuje nowy bufor na odpowiedz.

Przy odrobinie optymalizacji moze nawet nie alokuje wtedy gdy wyraznie
piszesz new ..

J.

do góry

On 9 Lut, 21:33, "Lelek@" <n...@n...pl> wrote:
> Nie wiem jak to sprawdzić, bo dopiero od tygodnia to robię :-) Nie wiem
> gdzie tam sa debugery, ktore coś pokazują :-)
> Podpowiedz mi :-)

Na pewno są jakieś debuggery, ale wyjątek powinien polecieć na
konsolę, po odpaleniu. Nie znam się na Androidzie, w Javie pisałem
sporo, ale parę lat temu. Podobało mi się, więc nawet myślę o tym żeby
się zapoznać z Androidem.

> Co do petli for(;;;) to może jej nie być. Chodzi o to, że jak długość jest 0
> len=0 to nie wolno mi czytać buf[] bo aplikacja się zamyka bez powodu :-)
> Jestem zdumiony tym zachowaniem.
> W ogóle jestem zdumiony, że nie ma UNSIGNED w całej tej javie i wszystko co
> sie chce robić trzeba robić na wiekszych, szczególnie boli uINT że trzeba go
> obrabiać w LONG i stale maskować & 0xFFFFFFFFL

Ja Ci radzę myśleć o Javie jak o czymś trochę mniej poważnym od C/C++
- pomaga:)
Ale wracając - możesz dorzucić
if(buf == NULL) poskarżsięnaekranieiwyjdź();
tuż za getBytes?

do góry

"J.F." <j...@p...onet.pl> wrote in message
news:bt06l6tprh86lbo6opbgkgll9qggti3cod@4ax.com...

> Przy odrobinie optymalizacji moze nawet nie alokuje wtedy gdy wyraznie
> piszesz new ..

> Ale to jest taka składnia javy. Inaczej się nie da zapisać alokacji bufora
> ... chyba, że go zadeklaruję

byte buf[] = {0,0,0,0,0,0,0,0,0,0...............} Tak 256 razy. Nie wiem co
to zmieni, bo samego byte buf[256] sie nie da w javie.
Nie rozumiem różnicy.

do góry