total bugs in DFM v3.5.7 and solutions

[krushnaji]

i used DFM v3.5.7 to create dictionary which has 100000 definations . i made dictionary and works fine but dictionary do not satisfy user because of bugs . i tried to find cause of bugs 4-5 days .

bugs are :
1) when definations are of large content , i got "java.lang.outofmemoryerror"
2) display of words is not vivid .
3) DFM has dark blue coloured index green coloured definations , this causes problem when theme background is black  or green . words are not visible so annoying user.
4)colour gets changed when translation listing is activated
5)indexes well as definations get underline when translation listing is activated
6)default text size is too large , only few words are displayed when screen is small

solutions :
1)bugs no 1 and 2 will disappear if coloured display is deactivated.
2)bugs no 3,4 and 5 will diappear if coloured display as well as translation listing is deactivated.
3)set text size medium for bug no 6

summary:
i think all bugs in DFMv 3.5.7 are because of activated coloured display . and there may be problem in translation listing function. i request developers not to activate coloured display by default . also i recommend that eliminate or delete coloured display option because it is unneccesory thing . it causes problem when theme is unsuitable . the default black and white string colour is fine and words are clearly visible and vivid and independant of theme colour background .people needs clear definations rather  than coloured definations . so i think coloured display is not important in dictionary development and have to eliminite to solve bugs .there are also problems in touchscreen phones due to coloured display.

[Gert]

i think all bugs in DFMv 3.5.7 are because of activated coloured display . and there may be problem in translation listing function. i request developers not to activate coloured display by default . also i recommend that eliminate or delete coloured display option because it is unneccesory thing . it causes problem when theme is unsuitable . the default black and white string colour is fine and words are clearly visible and vivid and independant of theme colour background .people needs clear definations rather  than coloured definations . so i think coloured display is not important in dictionary development and have to eliminite to solve bugs .there are also problems in touchscreen phones due to coloured display.

Thanks for your problem report ! It shows me that there are numerous problems with the coloured display and the StringColourItem class. So it really may be a good idea to deactivate the coloured display as default in a future version.

Gert

[krushnaji]

temporary solution to all dictionary makers:
to make "coloured display" deactivate by default to your end users, start your .jar file on your mobile and deactivate coloured display and then you will get generated .rms file which is visible on windows OS alongwith .jar file . this file is not visible on your mobile phone and then
transfer this file in your zip archive .
tell end user to transfer 3 files .jar .jad and .rms into mobile
now when end user will start DFM , coloured display will  become deactivated .

i tried to decode jar creater using netbeans to deactivate coloured display but i failed to open some classes . as i have little knowledge about j2me i didnt try further .

i request developers to do above job .

[Gert]

Following your postings, I released DictionaryForMIDs 3.5.8 where the "coloured display" is disabled by default.

Regards,
Gert

[daroojoo]

Hello, insert phrase at Properties as below to resolve the Problem "unsuitable theme".
backgroundColour: 255,255,255
not important, theme with any background color.

[Gert]

I will add this to the documentation occasionally.

Gert

[daroojoo]

hello, some of these, are not realy  serius problems. for example, it is not important what is defaualt. so explain for users at info about desirable setting. but more serious problems are these, i think:
- new line character: \n is not recognised by bitmap font.
- a bit slow (delayed) listing of search results. (not much important)
- we dont know how to chang defalt language 1 and 2, font colour. (not very important)
- background is not displayed with non coloured, translation list.
- heap memory error (before creating dictionary) and out of memery error (after creating), specially with large language 2 texts. I saw some options at Setting Up a  New Dictionary to set limitations for size of index, search and ... files. I wish to resolve latter problem by these options.
- I am an Iranian. My language is Persian. Mobile phones usually have needed characters to support Persian. but bitmap font doesnt support Persian comoletely. the Persian is completely different from Arabic but Persian writting language (In Iran and Afghanestan) largely uses Arabic letters. I has explained this problem with more detailed in another post at this ever topic.
- I think it is a good idea to enable set (or not set) a new capability for DFM so that created dictionaries ask for a opening password, after a few previous opening sessions. this option prevent from uncontroled coping or uploading of the product, and help creators (=dictionary developers) to  register new users. I has explained this with more details in another post at this ever topic.

[daroojoo]

Persian has a right- aligned writing. below sentence is a persian sentence meaning "I llike flowers".
من گلها را دوست دارم
bitmap font display it as below:
م ن گ ل ه ا را د و س ت د ا ر م
or:
م ر ا د ت س و د ا ر ا ه ل گ ن م (reverse, left aligned)
In fact  normally some letters at Arabic or Persian writting stick together when there is no spaces between them. for example if between م and ن there is no space, results: من
another example: گ ل ه ا  = گلها
but bitmap language doesnt perform it. I think you need a Iranian contributer to developed it for you. I try to call with one that i think can Help us, if you want. anyway it is only a sugestion. mobile phones usually have needed characters to support persian. (no seriuos need to bitmap font).

[daroojoo]

(continued).
about the password request that i expained at previous post:
users can evaluate the product at a few previos not-password-need sessions of openning and working with dictionary. password dialogue may include a sentence and a random-selected code like:
please send this code  as sms to (example) number *********** to get password. the code(example): 1265
the logical (masmethic)  relation between random code and password may be defined by dictionary developer.
the password request is a good idea for DFM to be popular much more than before.
thank a lot.