You could consider taking a BASIC course if those still exist, as ProRealCode/ProBuilder is based on the BASIC programming language. Of course, the ProRealTime language is designed for programming indicators and trading systems. Have you already reviewed the three manuals (ProBuilder/ProOrder/ProScreener)?

• ProBuilder Manual
• ProBacktest Manual
• ProScreener Manual

Learning to code takes time, a long time. But perseverance and patience will pay off. Definitely use the manuals listed above. You could also download free strategies from the ProRealCode Library. Study how others have tackled different problems and try tweaking their code to understand the logic. I came from a programming background, but this is how I transitioned to ProRealCode. As for learning a similar language, BASIC is the one, it’s syntax is very close – but variants will have differences and you might end up learning things that don’t apply. Stick with it, every new thing you learn and ever breakthrough makes it worth it!

Coding / Programming was all around me during the latter half of my career, but I managed to swerve / avoid it! 🙂 When I retired I surprised myself … no coding or formal language courses, I dived straight in and used Algos from the PRC Library as a basis.  I then coded simple Algos from scratch, later more complex. I still mostly have to trial my code to be confident it will work as intended … hence why I seldom help with coding problems on here. You will get there forexbull, just stick at it, but definately also use Algos from the Library on here as a basis for understanding what can be achieved.

Learning, all about something before starting, against, just getting stuck in not knowing anything are two extremes and the best way to start I guess would fall somewhere in between, since you always know ‘something’. The former, you may take time, learn a lot but generally not use most of it or very little. The latter, focusses you on the current problem, and where you need gain knowledge. Giving someone a box of tools doesn’t automagically mean they know what to do with then, however, if your doing ‘something’, it doesn’t take long before you realise you need something heavy, a hammer, to whack it!   Other than simple programming concepts like maths; logic, syntax, comments;  variables; condition blocks; loops and input and output, knowing what your trying to program can be a big problem. Though an algorithm itself can be tricky to implement and refine using the language, knowing the actual system your trying to program for, is the bigger issue.   The first thing that stood out with PRT and the ProBuilder lauguage was the system limits are either not posted or spread over the manuals and not gathered in a table somewhere or list of error messages. Though generally, this may not be much of the a problem with simpler algorithms, it becomes more of an issue in more complex and/or going to the limits or beyond the current language design. It’s only knowing, the limits, limit of language and system design that you can ensure you stay within it.   Further to that, code can appear in several different forms, screeners; indicators; proBacktest and proOrder variety’s all with a different subset of common and specific commands. Then the operational differences, like decimal places and active bar between indicators/backtest also the different ways errors are relayed or not ect…   In conclusion, PRT feels like a bunch of modules bolted together where there are nuts and washers missing in various places. There are a lot of good features but various parts don’t talk to other parts or incompatible or limited in some way. As time goes on in the life of a application, hopefully these issues will get ironed out, however, its not always that easy to achieve, especially in the short term. The initial design of the platform may have out lived its usefulness to be easily updated with out significant fundamental design changes, changes which require significant time and resources, that’s before adding new features which may be more easily added to a new design. Then there’s  backwards compatibility, copyright, licencing, regulations, and other loops to jump through, all while keeping the platform in usable shape and without raising the wrath of the users. Mostly, when you use software, your not using it from the first version or the beginning so all the prior info, details  and evulsion get condensed over the following versions which often appears as the new or different features from last version. To me this is like watching a film from the middle, your missing vital info which takes you off in a different direction, a direction not intended. This can lead to a process of using the software in a way that was not intended or envisioned, this because the core process is masked by the weight of the number of added features added over its lifetime. Though me being wound up by software is no way limited to just PRT, and is widespread, its something I begrudging live with. Not being totally immune, I do sometimes break out with symptoms of , head in hands; shaking head and occasion rants. Its often said that an error in software is called a ‘bug’ and eradicating the ‘bugs’ is called ‘debugging’ however, its really the code winding you up about all the errors you make, and a sign that you should be thinking about, what you’ve done, do you know what your doing, and where you should be going. regards all

All good stuff druby ! You have helped quite a few of us on here with your very detailed and analytical approach to problem solving. A Big Thank You!

I was going to say,  Good Luck!   but ‘Luck is not a factor’ When you don’t know anything, that just means, you have the biggest potential for improvement. One phrase I often squark out is: “Within reason, you can teach anybody anything,   but what you can’t teach them, is to recognise when it’s wrong! Learning something new means you’re going to make mistakes! If you’re going to make mistake, you may as well get stuck in and start learning. (circular logic)   Learning is a like a double edge sword, we try to use one edge to learn and improve, but we often catch ourselves with the other edge while wildly swinging, with not knowing, ‘our mistakes’. We don’t often realise, that there are a limited number of shrinking mistakes, because once we know of them, why would we want to repeat, the more we learn of them the better.   The more we know about the mistakes to avoid, the closer we get to no mistakes! If learning something new, causes mistakes, then does making mistakes, cause learning something new. (circular logic again) An example of this would be writing some code and getting an error message, and not know how to resolve it. If you intentionally write code to invoke errors, you know what caused them, then when they later popup, you have built up an immune response which can help you respond to what it may be.   Learning by mistakes… If you open up a new Indicator file, don’t write any code in it, and try to add it to a chart, guess what! You get an error message notifying you that the file need to be terminated with the RETURN keyword. Who knew!  , learnt that!, all Indicator files need the RETURN keyword, and I have even wrote any code yet, magic! Like the body, it takes a while to build up an immune response, if it looks like it’s not getting any better, you can always ask on PRC.