Всем привет. Написал несколькостраничный мидлетик. На эмуляторе SE W810 и на живой Нокии 6131 (кажись) все рабоает почти как надо, за исключением того, что под нокию не совсем правильно масштабируется разрешение. Запускаю на живом SE W810 - вторая страничка не отрисовывается, всю голову сломал уже. Варианты были: неправильно рассчитываю базовое разрешение и из-за этого рисую за пределы экрана; глючит вывод русского текста; забываю репейнтить... Может кто еще что подскажет?

Ты используешь Canvas, я правильно понимаю? Иногда возникают ошибки при вызове getWidth и getHeight если ты их вызываешь не в paint(). попробуй убрать вызовы getWidth и getHeight отовсюду кроме paint() и выкрутится через статические переменные. Может поможет. А вообще - код в студию.

Все не так просто... Код пока в студию вынести не могу, вечером только, но на словах сейчас расскажу, что получилось добиться. 
Я в своем мидлете использую kXML. Загружаю файл с инета, беру от него InputStreamReader, который передаю в процедуру отрисовки, там успешно инициализирую хмл-парсер, но как только делаю parser.nextTag(), вываливается ошибка org.xmlpull.v1.XmlPullParserException: Unexpected EOF. Причем перед первым nextTag() я делаю и reset() InputStreamReader'а и ready() дает true... Естественно в цикле я проверяю достижение конца файла и на эмуляторе это все проходит без всяких задоринок, да и на разных нокиях (все никак до самсунгов не доберусь) работает как надо. А уже на трех моделях SE валится. 

Вообщем дело, похоже, оказалось в глючности kXML'я. Он валился на самой первой строчке хмл-файла
<?xml version="1.0" encoding="UTF-8"?>
Убрал ее, и вышеописанная ошибка исчезла. Правда получилась другая, но это уже вопрос отдельный. Кстати может быть как раз из разряда getWidth и getHeight. 
И еще вопрос, может ли валиться из-за того, что я мимо координат рисовать начинаю или выхожу за рамки экрана?

Все может быть 

Но маловероятно, скорее всего ошибка в другом.

Если валится, то желательно код и ошибку в студию (кстати, у SE проблем с этим нет, так как в комплекте SE WTK входит On-Device Debug - очень удобная штука).

Скачал SE WTK, интегрировал с Eclipse'ой, повертел, покрутил... Но что-то или я ожидал бОльшего от On-Device Debug, или я не до конца разобрался. Правильно ли я понимаю, что можно только видеть консольный вывод мидлета и останавливать/запускать его когда захочешь? Или все же можно производить полноценный дебаг с просмотром состояний перемнных и т.п.? Ткните хоть на какой-нибудь туториал чтоли...
Ну и по коду... Я слегка локализовал место возникновения "ошибки", но легче мне от этого оне стало. Вот какая ситуация:

Вот тут вот и возникает непонятки, в месте, указанном комментарием 



Это был кусок метода public void paint(Graphics g) в обычном классе, конструктор которого выглядит так:


Код метода log до тривиальности прост:



Это второй вариант моего сообщения, потому что пока писал первый, немного разобрался и еще чудок продвинулся в своих изысканиях 
Сейчас корю себя за то, что глушу вывод экзепшина в 27-29 строках, но сейчас править код нет возможности, хотя пожелания и соображения все равно принимаются.

Да, вот еще и кусок того xml'я:

1. Попробуй вместо InputStreamReader использовать InputStream.

Я уже не помню почему, но у меня в проект с kxml пришлось отказаться от reader-а и использовать InputStream (сужу об этом, так как строки с reader-ом сейчас закоменчены).



2. Что в логи выводиться покажи.

3. Exception нужно обработать и хотя бы в лог вывести, что ему не нравиться.

что-то типа такого:


4.  Без вот это нельзя обойтись?



5. Вот это:

Может бросать exception, так как первой идет XmlPullParser.START_DOCUMENT, а потом START_TAG (хотя тут я не уверен и могу ошибаться.).

Да, это идея. Попробую.



Пока могу только что на телефон выводится показать





Ну это понятно, это я пропустил, сам виноват



в лог, конечно, можно не писать. Но ридер приходится сбрасывать на начало каждый раз, чтобы при возвращении к этой форме хмл-ник сначала читался




Ну с этим я вроде бы разобрался, это типа assert'а чтобы убедиться, что там должно быть именно это, т.е. что ты схавал свой хмл-ник, а не чужой. Он действительно бросает экзепшн, если чего не так, но я его ниже по коду ловлю, просто я не показал этого.

Попробуй обойтись без сбрасывания ридера, попробуй открывать заново, если нужно. (имхо, is.reset() - слабое это место в j2me)



Из логов я не вижу, что "Вот это выводится" для ctr. ctr - не обрабатывается. До него дело не доходит (судя по логам).

Вообщем, смотри что Exception-ы у тебя выводят.

Ну в общем да, все глохнет на <form>, согласен.
За наводки спасибо, буду крутить с ридерами и вставлять вывод экзепшенов, а там видно будет.

Вот тут кстати проверь еще, что бы parser.getText() != null;

А разве вот это условие 
не дает гарантию, что там что-то есть?

Но на всякий случай поправлю.

Я не знаю, что kXML генерирует в вот таком случае: 



Что будет между form и crt.

Ошибка в том месте:


была :


InputStreamReader заменил на InputStream

reader.reset() убрал

пока ничего не помогло.

Продолжаю изыскания...

Это сообщение отредактировал(а) AncleFedor - 20.8.2008, 23:11

Что-то мой предыдущий пост не прошел...
Смысл был примерно в следующем, я сделал вот так:


В итоге, в логе все-таки появляется строка 

А уж после этой строки - текст экзепшена, что я приводил выше. Т.е. parser.next() все же срабатывает и отрабатывается, но теперь я вообще не понимаю, почему происходит ошибка   

Еще вставил-таки проверку чтобы getText не был null, но ничего не дало.


eugine_s, может у тебя есть пример обработки хмл-ника с помощью kXML , которым не жалко поделиться? А то я уже задолбался с мельницами воевать...

Реально работающий кусок кода. В начале там есть строка strXml, в ней тот XML, который этим кодом парсится.



В случае, если у тебя XML выглядит так:

между событиями START_TAG на <form> и <crt> будет еще событие TEXT. И на него метод parser.getText() выдаст не null, а символы переноса строки и перевода каретки, т.е. "\r\n".

Shushpanchik, спасибо, попробую. 

Новости с полей. С кодом мидлета я пока не работал, но попробовал парсить разные структуры хмл. Так вот, когда хмл-файл скомпонован в одну строку (без пробелов, табов и переводов строк), моя ошибка пропадает, но появляется "Неожиданный конец файла". Т.е. мои выводы: kXML на сонериках невероятно капризен, нужно учитывать многое, в том числе и то, что kXML воспринимает перевод строки как событие типа TEXT.

Расследование продолжается...