PDA

View Full Version : Nokix repeat alarm clock problem



slash666
08-02-2006, 05:02 PM
Hi guys,

Ive been playing with the firmware using the nokix scripts from YAK however i have found a small issue with the repeat alarm clock function. Once a repeat alarm has been set you cannot save changes to the alarm time without unselecting a day, saving then reselecting it. Chaning the alarm time without changing a day mark does not bring up the "save changes?" screen, pressing back just goes to the previous menu.

I have had a look at the source files but there is no project available for this app and i have to admit im a little out of my depth there!

Can anyone let me know how to fix this problem?

nuukiaworld
09-02-2006, 12:00 PM
I confirm this thing on 6110, too. The UI works logically but it is actually impossible to change already set alarm time without first disabling the alarm or changing the weekdays.

For the user's point of view, should it ask "Save changes" even if you have not changed anything in the weekday menu? But it is against the Nokia's UI logic?

Or should pressing "Back" in the weekday menu (without any changes in the weekdays) save the changed alarm time and exit the alarm function, instead of backing back to the Once/Repeat menu? :???:

Programmatically this is a rather simple issue but from the UI's point of view it is not so clear. :roll:

slash666
09-02-2006, 05:57 PM
Hi

What i beleive should happen is that if either the time OR the day settings are changed it should give the "save changes?" screen. I know it is not obvious then what changes youre saving but if it saves both the time and the present day settings then i cant imagine there would be a problem.

Maybe its just me but thats how i would like it to work. I dont know if the nokia UI would prevent this however.

Maybe if repeat is chosen there is another menu to change days or save without changing days. This would obviously add another menu but it would prevent having to go to the days menu at all if you didnt want to change it.

How do others think it should be?

nuukiaworld
21-02-2006, 01:27 PM
Once a repeat alarm has been set you cannot save changes to the alarm time without unselecting a day, saving then reselecting it.Actually you can save the changed alarm time simply by unselecting/selecting any day and then pressing "no" in "save changes" dialog. In this case, the new alarm time will be set but the repeat days will not be touched...

I couldn't invent any better solution to this issue than the following slightly non-orthodox one: If Back is pressed in the days menu (without any changes to the existing day boxes, so no "saved changes" is displayed) and there are already some days selected (set earlier), the alarm will be set instead of backing back to the "Alarm once/Repeat alarm" menu. I.e. if you have existing day selections, you could simply accept them by pressing "Back" in the day menu. (Accepting something by pressing 'Back', great... :roll: )

Respectively the app could also catch the case were the user clears all days and saves the changes when re-setting the alarm. Now it actually changes the alarm to a "Alarm once" alarm, even you do it through the "Repeat alarm" option!

yak
21-02-2006, 10:51 PM
I took a look at the 3410 (on which the script was based) and it seems that the menus with checkboxes have an additional option there. It is possible to cause the "Save changes?" dialog box to appear no matter if there were changes to the boxes or not.

Maybe we should patch the menu system to provide that option...

nuukiaworld
22-02-2006, 07:10 PM
I disassembled the menu routines a bit and found the following features that are not included in NokiX:
Menu dispmode bit 1 (0x02) is "MDM_NO_CONFIRM". If it is set with MDM_SWITCHABLE, then no "Save changes?" dialog appears; all changes are saved automatically.
Message 0x397 means that Back is pressed in a switchable menu (triggers the comparison to check if any changes were made)
Modding the internal variables of the switchable menu can be used to change the situation when the "Save changes?" appear. (See the attached nrx for locating them.)
The attached modded version solves the slash666's problem by changing the switchable menu variables when it is about to close. As the result, the MSG_SWITCHABLE_MENU_STATUS is sent whenever any day is selected, independent of the previous states of the days. (Dispmode 0x02 is used to skip the unnecessary "Save changes?" dialog, too.) 8-)

It also prevents the possibility of clearing all days of a repeating alarm: whenever no days are selected (the previous states of the days do not have any effect now), Back returns you to the "Alarm once / Repeat alarm" menu.

yak
22-02-2006, 08:51 PM
Mhm, cool. May I include it in my scrips pack?

About the MDM_NO_CONFIRM, I fount it too some days ago and have it since then in my includes (with different name but yours is better).

-- added --

Huh, I've already transfered all my scripts to new SDK but your repeated alarm clock is of course in the old format. Ok, I will transfer your changes then.

One more thing, on what models will your solution work?

-- added --

I've taken a look at it. Nice. By setting a negative of +4 to the +6 we can force it to always save the changes :D.

nuukiaworld
23-02-2006, 07:04 AM
Mhm, cool. May I include it in my scrips pack? – Huh, I've already transfered all my scripts to new SDK but your repeated alarm clock is of course in the old format. – One more thing, on what models will your solution work?Of course, you can include it. Your sources are GPL, so then are these, too. This applies also to other scripts I posted here, e.g. calendar week number calculations, thermometer screen saver, "menu_reset()" in RPN calculator etc. It is for our common good that the NokiX official scripts are developing revealing new tricks to the users.

I kept it in the old format because I expected to see a converted version soon... Just diff/merge the C files and the NRX to update your version. At the same time you can also remove the out-commented unnecessary code lines and possibly optimize the code more (because there is no possibility to answer "No" in "Save changes?" dialog anymore).

It has been tested in 6110 only. However, according to my visual inspection of 5110 & 3310 disassembly both MDM_NO_CONFIRM and manipulating the switchable menu variable (and the locating code for it) should work on those, too.
I've taken a look at it. Nice. By setting a negative of +4 to the +6 we can force it to always save the changes :D.Negative or logical not... (edit: or + 1 or anything that makes words [+4] and [+6] unequal...) The code above uses fixed value of 0 because then it also removes the possibility to unselect all days of a repeating alarm. (If no days are selected, the [+4] is zero (== modified [+6]), and the menu thinks that no changes were made returning back to the "Alarm once / Repeat alarm" menu.)

I guess that the structure with those switchable menu values contains also other interesting variables that can be used to monitor/manipulate the menu operations. :-P

yak
23-02-2006, 11:49 AM
I decided not to use the MDM_NO_CONFIRM flag. It's more intuitive this way I think.

A bit OT. The Dialogs. Maybe you have played with the flags while testing them? What flags do you know? For example how to create a time/date dialog that will skip the ":" or "."? I want to investigate this but wanted to ask first.

nuukiaworld
23-02-2006, 12:04 PM
I decided not to use the MDM_NO_CONFIRM flag. It's more intuitive this way I think.:( one extra key press is then required, and it is even on the other Navi than the previous key press; but I respect your decision.

I think that the behaviour of "Save changes? - No" was illogical in the original code (if the alarm was already set): It ignored the changes to the days, but still saved the (possibly) changed alarm time showing "Alarm set" message. I think that "Save changes? - No" should ignore all changes, including any changes to the alarm time. AFAIT (T=tested), that behavour can be achieved with the following simpler code in hooks.c:
case 0x1f00:
{
if(app.set==2) msg=0x6ba; /* replacing, the alarm will be set */
else
{ /* we get here if the week menu was chnaged but the changes was canceled */
// Ignore all changes, just leave the alarm function as it is
send_message(0x5ea);
msg=MSG_NOP;
}
break;
}The only thing that I have found out from the dialogs (they are awful to analyze in disassembly) is that DF3_READ_ONLY seem not make an input dialog 'read only' but disables * and # completely instead; allowing entering only pure numeric digits (very useful).

yak
25-02-2006, 12:34 PM
The reason why I've decided to keep the confirmation dialog is that it is more intuitive this way. Normaly, when you press "Back", you don't expect something to be sent/set/saved. When you have the dialog, you can see what is happening.

I agree about the canceling of all changes when "No" is selected in "Save changes?" dialog. Your code works (thanks), i've only replaced the send_message(MSG_R_LEAVE) with msg=MSG_R_LEAVE.

I've also made the "Alarm once/Repeat alarm" menu to automaticaly select the current setting upon menu opening.

Yes, the DF3_READ_ONLY flag was apparently an accident :). I've defined it in the early date when I didn't know that the window ID defines the kind of dialog.

And at the end I must admit you're quite good in all this. Thanks for your help and contributing to NokiX. I received many signals from users, that your scripts are tested and bugs-free :D.

Daryl Saludares
26-02-2006, 11:41 AM
And at the end I must admit you're quite good in all this. Thanks for your help and contributing to NokiX. I received many signals from users, that your scripts are tested and bugs-free .what about the "bell alarm animation"? because once the scheduled alarm time is reached the animation plays once it doesn't loop, i think the animation of the bells are looping but in my modified flash, that is the case. i've used the latest repeat_alarm_clock.nrx (3310 V06.39B/ENGL language only)