Platform V12 – Your Biggest Annoyance Currently??

Forums › ProRealTime English forum › ProRealTime platform support › Platform V12 – Your Biggest Annoyance Currently??

Viewing 15 posts - 16 through 30 (of 34 total)
1 2 3
  • 05/14/2025 at 4:14 PM #247123
    GraHal

    Maybe I have missed something?

    If we had no top pane and stopped Systems appeared in the non-running Section (like they used to before we had the top pane) … then we would not need to add z’s anyway??

    I found it a faff / annoyance to add 14 z’s earlier today simply because otherwise (after acknowledgement in the top pane) the 14 Systems would ‘dissapear’ into the not-running Section.

    So Peter … are you saying that you are happy (for once! 😉 ) continuing with the top pane as is and you keep adding z’s?

     

    05/14/2025 at 4:49 PM #247126
    PeterSt
    GraHal wrote:

    So Peter … are you saying that you are happy (for once! 😉 ) continuing with the top pane as is and you keep adding z’s?

     

    It looks like it, Yes.

    But in response to your stance about when the top pane was not there yet – it would have come down to the same annoyance AND solution. Thus, how it was :

    System is thrown out. It showed at the top of the not running systems (or maybe it was even worse – in the middle somewhere ? but never mind for my gist);
    Then we had to click the yellow mark in order to be able to restart it and … gone it was into blau Hineins. Actually the same as happens today when it moves from the top pane to the bottom (Not Running) pane. So the solution for that is the same as well : put that z in the comments column and sort on it. No difference with today’s top pane and without it. Anyway the small work flow as of now, assuming that after 100++ thrown out systems you really don’t need to know the Why of it :

    1. Put a z in the Comments column for Thrown out System A. Same for System B.
    2. Click in the Yellow mark of each of them (two clicks in this example).
    3. Have the bottom pane sorted on the comments column (of not already).
    4. Mark those two for starting them. Click Start Selected.
    5. Remove the z out of those two, maybe after sorting on the comments column first if not already so.

    Point is : besides this is super fast now with 150 not running systems (I think the two systems took me 20 secs for the whole procedure), you can not really make mistakes any more. And prior to this procedure ? what about 4-5 minutes for two systems ? find the name, check and double check whether the name is the correct one after having sorted out the name (from an always  too small column (grrr) or from a popup maybe still there) and then still it never felt safe (am I really starting the right one ?)
    I like to do this blindly without “danger”. And this little workflow allows for that.

     

    PS: I already know for a while that nothing disappears ins blaue Hineins, but that the lists comply to the sorting order. So all you need to know the exact name of the system you are (implied) moving from one pane to the other and you will find it (when sorted by Name). But the point is of course : knowing that name with certainty. And the Version obfuscates (because same Name but different versions of it may exist). So hmm … But that Comments column really solves it.

    05/14/2025 at 5:09 PM #247129
    GraHal

    Okay let’s all keep zzzzzzzzz ing … for a while anyway until we, maybe, think of something better?

    It is though yet another workaround / ongoing faff …  Systems assigned to not-running Section (e.g. for bad performance) will need to be de-zzzzed else they would end up getting started again (when not wanting to!)

    I’m feeling tired already zzzzzzzz  !!!! HAHAHAHAH

    05/14/2025 at 5:15 PM #247131
    druby

    I must have got my wires crossed, you cant start the duplicate system in the top pane, it dumps it in the bottom but with a tick.

    I was distracted by the many ways you can acknowledge  a stopped system, I think the count is 5, if is part of multiple stopped, but not one way to start it from the top pane.

    It would be a good idea to tweak the variables on a duplicate or a stopped system before starting, rather than the full create process.

    Also additional detailed logging of the stoppage reason would be good.

     

    05/14/2025 at 5:27 PM #247132
    GraHal
    druby wrote:

    it dumps it in the bottom but with a tick.

    No … if it did above then – for me – all would be good and no need for zzz ing.
    The acknowledged Systems get dumped in the bottom but not with any tick against them.

    druby wrote:

    tweak the variables on a duplicate or a stopped system before starting, rather than the full create process.

    Any duplicated System would not show / preserve historical performance and so nothing gained by duplicating … unless I am missing something again?
    Also once a System is on ProOrder then variables are shown in ‘ONCE format’ and so no population of optimiser etc.
    I keep copies of original Systems – with optimiser populated with variables – on my PC for ease of tweaking / re-optimisation etc.

     

    05/14/2025 at 7:36 PM #247133
    druby

    It’s another part of the ironic tail, a duplicate system from the top panel, is put in the bottom with a tick, but not when you acknowledge the original stopped system. Yes if it did, the Z’eds could be saved for bedtime.

    Unless i’m mistaken, a duplicate or an edited system are the same when referring to a new version stamp. In both cases the  history is restarted. Its only the re-starting of a stopped system that preserves historical performance.

    As I recall, in the backtest and proOrder window under the proOrder tab, the variable’s can be altered, if it’s these which become the once variable values, then it would be a nice feature to have access to these when creating a duplicate. Also if access were also for a stopped system, then a simple tweak could be done  rather than the whole process.

    Not saying it’s ever going to happen but it would be nice under those situations.

    It looks like for the duplicate you can change the instrunent and timeframe, if a duplicate worked directly with that change, ok, be probably need different values for different timeframes and instrument. Its quite easy to determine the timeframe, but a bit of a faff to determine the instrument with a level of accuracy and a stopped system may no be so easily re-started within the  10k preload bars

    Not tried it in backtest and beyond but only in a indicator to determine between (DFB) DAX, wall street and bitcoin as a test. By the way this was to recognise the instrument similar to gettimeframe determine the timeframe. There’s an element of faff to it. But if your on the DAX certain values were used but if you changed to wall street different values were used, same with the timeframe.

    I only mention it since thats all that you can appear to do with a duplicate from the ProOrder AutoTrading window.

    05/14/2025 at 8:32 PM #247139
    GraHal
    druby wrote:

    In both cases the  history is restarted. Its only the re-starting of a stopped system that preserves historical performance.

    Yes your assumptions above are correct.

    05/18/2025 at 1:29 PM #247272
    GraHal
    GraHal wrote:

    If anybody knows if this will be fixed in v13, please let us know and put us out of our misery??

    PLEASE does anybody have an update on the DoV window and it’s rogue sizing causing us to drag the top bar down dozens of times per day to see the scroll bar etc (often 4 or 5 times each time we use the DoV window!)??

    I am feeling desperate now – with v13 drawing nearer – that PRT may not be aware (surely not???) or the problem is not seen as a high priority (surely not???) or the problem is too difficult to fix so it is being left as is for yet another Version???

    We’ve been suffering with this problem for several years and several PRT Versions!

    Somebody must know something, surely?? Seems we get no updates ever direct from PRT on this Forum so it’s over to Moderators or Nicolas PLEASE for an update?

    05/18/2025 at 3:48 PM #247276
    druby

    Hi @GraHal, I recall you mentioned this before however, at that time it was far beyond my understanding and didn’t look into it any further.

    From your image, I can see you have possibly 66 variables set and I can see the DoV has no scroll bars.

    I tried to re-create problem several times, with 50 variables, but couldn’t, the scroll bars always showed up. It wasn’t until I saved and re-booted PRT that I re-created it.

    It appears that on re-opening the DoV with a large quantity of variables, that the default position of the DoV window and the large number of variable’s pushes the DoV beyond the bottom of the screen. Also the scroll bars are no where in site or look that there even there off screen.

    After a lot of faff’ing I found a solution in my case, when presented with the situation, if I added 1 more random variable to the DoV,  the scroll bars appear, when added.

    Scroll-tastic!

    The extra variable needs removing, but if left I don’t think it does any harm as I can see at the moment, but the scroll bars are there to remove it.

    I hope this is of some help.

    Regards

     

    1 user thanked author for this post.
    avatar GraHal
    05/18/2025 at 4:46 PM #247277
    druby

    Another thing to take note of is, the DoV window appears in a different location depending on how you open it, back-test tab,  top, side or AT tab.

    Also the position of the chart and size  may have a influence on where the Modify ProBacktesting window appears, but the Modify Probacktesting window position and size has an affect of where the DoV window opens.

    The best position for opening the DoV is with the Modify ProBacktesting window is  minimised to the degree that only the top DoV button is showing, and tthat then is at the top of the screen, and then open the DoV.

    This places the DoV from the top of screen, which helps if you need to make the DoV window smaller to fit the screen. This can aid the scroll bars appearance depending on how many variables are in the window and how many times you need to do it, depending on screen resolution and font size. Basically, I suppose something like your doing now.

    May not be an ideal solution but having options is better than no options.

    1 user thanked author for this post.
    avatar GraHal
    05/18/2025 at 5:14 PM #247278
    druby

    Further to above, when you have control back of the DoV window, closing the DoV window doesn’t appear to change the DoV window when you open it again, unless you close the Modify Backtesting window, then it reverts the DoV back to the scroll less version, size and position.

    So as a procedure

    1. open Modify Backtesting window
    2. drag the bottom of the window to minimise it to only show the DoV button at top
    3. drag whats left of the window to the top of screen
    4. Open the Dov window, from button, which should be from the top of screen
    5. drag the top of that window to near the bottom of the screen
    6. Enter the random variable in the DoV list and add.
    7. drag the DoV up the screen so the whole window fits on screen, or back to the top.
    8.  if this is not enough, then 5 – 8 may have to be repeated till window fits screen

    Perhaps if we compile a proBacktest file with enough variables added to cause fault, and a logical description on what and how it happens, maybe that will help PRT getting it fixed.

    1 user thanked author for this post.
    avatar GraHal
    05/18/2025 at 8:12 PM #247280
    JS

    I had never encountered this problem because I don’t use that many variables, but I just tried it with 45 variables and I think I see what you mean…

    You can fix this issue by moving your mouse to the top-right corner of the DoV window and dragging the corner to the right using the “right-angle” symbol…

    Something isn’t quite right there, but if you move it back and forth a few times, the scroll bar appears…

    2 users thanked author for this post.
    avatar GraHal, avatar druby
    05/18/2025 at 9:04 PM #247283
    JS

    I think the message to PRT should be that the automatic scaling of the DoV window doesn’t work correctly in relation to the number of variables in the DoV window…

    1 user thanked author for this post.
    avatar druby
    05/18/2025 at 9:20 PM #247284
    JS

    Message to PRT support send….

    05/18/2025 at 9:22 PM #247286
    druby

    Well spotted @JS, it seem to bring up the scroll bar if you grab either top corner, as you say, with the diagonal window re-size icon and drag the frame vertically smaller,  than the presented current size.

    In actual fact , if you just drag the top of the window down ,it brings up the scroll bars too.

    With multiple monitors, one on top of other, when you then drag the window up to get it fully on screen, the initial present variables frame is set to the number of listed variables in size.

    It looks like, when you make it slightly smaller, so not all the variables fit in the variables frame, it recognises than now ,  it need the scroll bar.

    Even with multiple monitor’s if you can just drag up the window so fully on screen(s), the scroll bar doesn’t appear till you start to make the frame smaller, or add another variable so it doesn’t fit the current frame size.

     

    1 user thanked author for this post.
    avatar JS
  • Author
    Posts
Viewing 15 posts - 16 through 30 (of 34 total)
1 2 3

Find exclusive trading pro-tools on ProRealCode Marketplace

Similar topics:
transferring saved workspaces from v11 to v12
v11.1 vs v12

Create your free account now and post your request to benefit from the help of the community
Register or Login