Programmable Floating Keys

[RDS]

The feature to enable programs to be run from the Floating Keys is very powerful.  

Is there any way of editting these keys, for example to change the text on the button, or to be able to view the details for a particular button that were entered when the button was first activated.  I have one button that is not doing what I expected, so I was just curious to know what is in the pull down list of the 2nd field.

[St1ngr4y]

Hi RDS,

https://www.hornby.com/forum/programmable-floating-keys/

Idlemarvel posted this a few weeks ago, which may help.

Ray

[RDS]

Hi Ray

Thanks for taking the time to reply but this is overtaken by the release of v1.56 because you CAN now use the buttons to run a program because an extra line has been added to the drop down options.  I think you will find it useful, with the programs you have written. By the way did you sort out your 'multiple lines, blue background' query from the other day?

Dave

[RDS]

Futher to my initial question here, which if anyone can help, I would appreciate an answer, I  would like to know how the delete button (picture of a dustbin?) is intended to operate on the Floating Keybar.  I have some buttons that I put on as a test and I cannot now delete them.

[RB51]

Just click the program button you wish to delete - as if you were running that program - and then click the bin. There will be a confirmation dialogue which you agree to, and your done. R-

[St1ngr4y]

Hi Dave,

Yes, thanks to your guidance. I have been splitting up one or two large programs into more manageable sizes, and then bringing them back together using the chain command. For example, engine shed to turntable, turntable to main line, main line to station platform. To do this I needed to delete multiple lines at various points, which I can now do quite easily thanks to your advice.

Ray

[RDS]

Roger

Thanks.  I thought I had tried that but it just ran the program.  I will have another go.

I would still like to be able to edit existing settings as well though.

[RDS]

Ray

That's good.  I too have been using the Chain command and it now works perfectly everytime.

I am doing the same as you in splitting programs up again that I had only combined into one larger program because of the earlier difficulties with the Chain command. 

[96RAF]

You will have likely seen that you can drag the Floating Button bar about your screen. I park mine at the bottom in the blank footer area.

Whilst running the screen at restore size (i.e. less than full screen) for the purposes of getting at my screen grabber icon I noticed that the Floating Button bar stays put and if you minimise RM the Button bar is still where you put it - odd that. Same goes for if you are reporting a snag or if you have a Programme open for editing.  Those screens hang around, so if for any reason you have them suddenly disappear when you were doing something just minimise RM and they may well be behind it.

[St1ngr4y]

I do have one issue with the chain command which I have reported through the help system, but haven't had a reply on yet. Many of my programs start with a series of point change commands to set the route for the train in question. Since switching to ADS8 decoders, I have been able to seperate these changes at one second intervals in a program, because there is no longer a need to wait for cdu recharges. Typically, a program might have ten or so point changes in the first 10 seconds of the program.

In the example I have quoted of splitting large programs into, say, 3 smaller programs, then chaining them together, obviously when the chain commands "merge" the program steps back together at "run time", there is little or no interleaving of commands i.e. the commands should be obeyed more or less as they were in the original composite program. What I have found is that when I run the new program consisting solely of three or four chain commands, the program timer clock which comes into view at the top of the screen (red characters on black background), actually starts at 3 or 4 seconds instead of 0.00 seconds, and for the first few seconds there are lots of very rapid point changes - far more rapid than one per second. It is as if ...

1. The clock is being started before the merging of the programs has completed

2. During the first few seconds after command execution starts, it is trying to catch up with the clock which has started a few seconds too early.

I have found a way around it as a "fudge" fix. I place a "Message display" command in the program at 0.00 followed by the first chain command at 5.00. This provides a few seconds for the merging process to complete before the point changing commands are reached in the first chained program.

Ray

[Fishmanoz]

Any chance this is a processing backlog in your cpu rather than an actual RM problem?  Would depend on what cpu you have, how many cores and how fast. 

[idlemarvel]

Question for HRMS, can RM exploit multple cores?  AFAIK RM is basically a Visual Basic app and probably single threading.  But you're right fishy, if you have other background tasks running they could use other core/processors.

[St1ngr4y]

Hi Fishy,

My pc is an Advent E5300 with a Pentium Dual-core 2.60 ghz processor, 2 gb memory, running 32-bit Window 7 Home Premium.

I think that should be powerful enough, don't you?

Ray