hi… see if this is getting anywhere!

druby

// !!! default timeframe 1 minute


timeframe(20minute, updateonclose)  // update only every 20 minutes
close20m = close                    // 20minute close
barIndex20m = barindex              // 20minute barindex


timeframe(1minute )                 // 1minute timeframe
close1m = close                     // 1minute close


if barIndex20m <> barIndex20m[1]then           // end of 20minute bar!
drawvline(barindex[20])style(dottedline,1)  // denote with vertical line

// calculate the 20minute bar average based on last 20 1minute bars
avg1m = average[20](close1m)   
// display this average over the relative 15minute bar width            
drawsegment(barindex,avg1m,barindex[20],avg1m)style(dottedline,2)coloured("blue")

// table variables
print(close20m[1]) //  this [1] aligns up  20m close with the avg1m value
print(avg1m)       //  in table 
print(barindex20m)
endif

return close20m coloured("red")as"20m Close",close1m coloured("lime")as"1m close"

Don’t laugh …

I saw the original date of this topic and thought : wait, I think it was so that I found a way after all and this must have been *after* the date of this topic (May 24). Not being sure about that, I googled for it in order to find back that particular discussion. Ready for the laugh ?

AI-overzicht

In ProRealTime (PRT), specifically within ProRealCode forums, PeterSt is a prominent user who has extensively discussed, tested, and sometimes challenged the limitations of array variables and tick-level data, particularly in the context of ProOrder automated trading strategies. 

 +2

Array Variables and Tick Data according to PeterSt’s discussions:

• Tick-by-Tick Data Challenges: PeterSt has noted that while tick-by-tick data is crucial for strategies, backtesting with it can be inconsistent, and it is sometimes tricky to properly leverage within the strategy code.
• Arrays within Strategies: Arrays (variables denoted with $) can be used to store data over time or within bars. PeterSt and others in the community have clarified that arrays can persist across bars, contrary to early understandings, allowing for the storage and computation of historical data points.
• Data Access Limitations: A key topic in PeterSt’s discussions is that while you might be able to print or graph tick data within an indicator, storing that specific, highly granular tick data within an automated strategy (ProOrder) is not always possible.
• Alternative Approaches: PeterSt often engages with other users (like Nickolas and Roberto) to find workarounds, such as using ONCE to declare array variables to ensure they are properly initialized before use. 
•  +3

————————–

And this with the notice that I left the working out to the community here and never heard back about it. Btw, this surely was not about engaging different time frames. Anyway :

So Yes, within Indicator logic, array elements can be filled with “bar data” from within that Indicator code. The array elements sustain, contrary to any normal variable.

The programming within this “logic” will at least be buggy or hard to debug and analyze, because nothing is really made for it. Also, the working with arrays themselves within PRT I deem a sheer pain (this is personal), which does not help in attempting these things for real myself. And oh, @druby is surely often/always involved himself in these matters (arrays) but I think that in the end nobody really grabs the real merit of it all – it is and remains unofficial that this can work. Please note : most of the attempts end up in not understanding because it is very hard to see through what internally happens.

Important

What I did try once was at the rough level trying to incorporate this “array behavior within bars” (like storing tick data) from within Strategy Code and then by means of calling Indicator code. This plainly can not work because Strategy code is meant for Backtesting (and Optimizing) and in the end ProOrder; in that environment no tick data is processed anywhere, thus also not in Indicator code. Indicators are for the graphical environment (!). Additionally, while Indicators can return a value when called from Strategy Code which would really work within ProOrder as well (we all know that) it is still so that whatever the indicator is, it won’t work with tick data. On-screen (graphically) Yes, and within that environment Array elements can be written by the tick. And so … this could be useful for manual trading and literal “indicator” stuff, it is useless when ran on PRT’s servers (outside of the graphical environment).

That an indicator (code) can also be used as a sub routine, is something unrelated. Read : The existence of calling an indicator from within Strategy Code is fully justified. But for way different objectives.

Last word : in an example somewhere, related to the new ProRealCode forum/community environment, Nicolas kind of in between the lines told that Indicators nicely could be used as subroutines (these days), which he also excessively used in his examples. He hinted / implied that there was no necessity to wait for the due real sub routines because the indicators can do all. Well, I can fully subscribe that. And for example, these days they are not a bit slower then de sub routine code being in the main program code itself.

But … force that by trickery into using tick data after all, and you will get no response from the Strategy Code any more. I don’t think it is possible, but would it be, then know that Nasdaq presents over 10K ticks per second once the market is open (IG could even be more). And no way that will work on the PRT servers. On your own with a really fast PC this is already cumbersome – and there you are the only user.

Curious what AI will make of this post. Haha.

Peter