Accelerators ....
I choose to not implement any Accelerators Editor for following reasons:
We have two ways for managing Accelerators. Accelerators stored in Resources:
call 'USER32.LoadAccelerators' D§hInstance ID
mov D§AccelHandle eax
and Accelerators stored in Data:
[ACCELERATORS:
U§ &FVIRTKEY__&FNOINVERT &VK_F1 M00_Help
&FVIRTKEY__&FCONTROL__&FNOINVERT 'F' M00_Find
&FVIRTKEY__&FCONTROL__&FNOINVERT+FLAGLAST &VK_8 DRAWLINE]
[ACCELNUMBER 3 FLAGLAST 080]
call 'USER32.CreateAcceleratorTableA' ACCELERATORS ACCELNUMBER
mov D§AccelHandle eax
__________________________________________________________________
; In both cases, the main message loop looks like this:
__________________________________________________________________
jmp L1>
L0: call 'User32.TranslateAccelerator' D§hwnd D§AccelHandle Firstmsg
call 'User32.TranslateMessage' Firstmsg
call 'User32.DispatchMessageA' Firstmsg
L1: call 'User32.GetMessageA' FirstMsg 0 0 0
cmp eax 0 | ja L0<
call 'USER32.DestroyAcceleratorTable' D§AccelHandle ; <<<<<<<<<<
call 'Kernel32.ExitProcess' D§FWparam
The only difference between these two ways is that, when storing Accelerators in Resources, upper '<<<<<<<<' line is not required whereas it is, with Data Accelerators. This is not a great inconvenience..
On the other hand, having Accelerators table(s) in Resources have several disadvantages. The first one is bound to the way RosAsm holds the source and the resources: There is no way to store any ID Equate in Resources. So, having an Editor for Accelerators would require we enter the IDs by number (like all other Editors). This can be an added pain, compared to simple Data storage (which allow Equates, as usual). For example, if you add an item at the beginning of a menu, all the following Menu IDs are changed. We just Click on [Store IDs to ClipBoard] and paste our new Equates set. But, if these IDs are reused in Accelerators (which is usually the case), we would have to change all the bounded Accelerators IDs by hand.
A solution would be to implement an Equates parser between Source and Resources jobs. This would be possible but I consider this as much too much work for a such an easy problem.
A last point is that Data Accelerators are a bit easier to modify at run time, for example to provide a user customizable list than one stored in Resources.
~~~~~~~