I am trying to get a more realistic feel for dip buying entries (similar to work done in WL 4 and by Dr Koch's addon tool) and I am using the following. I was hoping people would weigh in on whether this is working as I intended. This assumes you are using WL Pro and have Fidelity 1 minute data for your intended symbols.

CODE:
Please log in to see this code.

Dave,

You might want to take a look at Setting Priority for AtStop/AtLimit Orders in Community.Components. Robert has already coded this routine but with some more checks.

Thanks I will take a look, but there's something exciting about re-inventing the wheel :P

I just tried this and every symbol throws a null reference exception (writes a debug line with "Object reference not set to an instance of an object."). I followed the example:

CODE:
Please log in to see this code.

Any thoughts on this?

Edit: In between those lines of code is the actual code executing the trading system -- the call to SetTimeOfDayPriority is the last line of Execute().

It would throw a null pointer for me when it could not find intraday data for given symbol. In your case it could be because "HiLoLimit (Naz 100)" dataset does not exists or there's no intraday data for the current symbol in that dataset.

Dave, the method is memory intensive so I'd recommend using a minimum of 5-minute data or higher. I'm not sure if memory is the trouble you're having, but Eugene's implementation seems to work fine for me. Check out the code on the Wiki site and take a look yourself. Please improve it! :)

Edit!
Now I see it - in the MSB backtest if (as avishn suggests) the DataSet doesn't exist.

Wow, this really works well ;) Check out how it found these unrealistic spikes in the Dow 30 Daily data. It's worth running this method just to clean up Daily data.

CODE:
Please log in to see this code.

In fact, we should be able to put a corrections file together and a script to apply it... something else to work on.

My bad -- had a case sensitivity issue in the name of the dataset. Working now although it complained about running out of memory (but still completed). The method I posted above didn't give that message but gave basically the same results. Plus I can pat myself on the back for writing my own code to do something that was already available. Maybe for my next project I'll write a MessageBox class of my own :P

QUOTE:
Working now although it complained about running out of memory (but still completed).

If you have 3+ Gb RAM, these tweaks can be applied:

Is Wealth-Lab Pro 5.x able to use 3 Gb of RAM?

Some more ideas to help Out of memory problems.

(WLD 5 x64 is the solution, though an x64 build is not currently available to WLP.)

On a semi-related note (wiki pages)... I wanted to add more information to the "Setting Priority for AtStop/AtLimit Orders" wiki page but it won't let me edit it even after creating an account/logging in. Do I understand it correctly that the wiki is not open for editing by external users?

Yes, we had to protect the pages from wiki vandals. You're welcome to leave your corrections (after quick registration) by following the "Discuss" link on the page. HTML and Code tags are supported. Let us know once you're done to catch our attention, so we could embed your info on the wiki page.

Got it, thanks.

EDIT: Nope, gives Access Denied when trying to post a message through the page Discuss link (after logging in).

CODE:
Please log in to see this code.

I thought about going after data in a Provider DataStore (it's a good idea), but then there's a problem using it for a a Provider that doesn't use a WL5 DataStore. Anyway, we'll have to see if there's another tweak to force the G.C. to toss out the garbage sooner, but it doesn't seem like we have much control over that.

QUOTE:
EDIT: Nope, gives Access Denied when trying to post a message through the page Discuss link (after logging in).

Hmm, that's odd. Maybe a cookie problem? If you don't succeed after refreshing the page, please just leave here what you have and we'll get it done.

Eugene I've done those tweaks (although it now occurs to me I should do them again since I've upgraded WL to 5.6).

Would you guys consider some kind of inter-process communication (remoting for example) that would allow the fidelity 32 bit components to sit in their own 32 bit process and communicate with a full 64 bit version of WL Pro? I'd ask Fidelity but I think they're too busy trying to find the API documentation :(

One other thing I just discovered. After applying the 4 GB patch (from NTCore referenced in the link from Eugene above) to WealthLabPro.exe I am seeing drawdown numbers that are not correct. When I restored the original version of the EXE they went back to normal.

I changed the position size to $1000 per trade which insures for the system I'm running that all trades get taken. With the original EXE I get a drawdown of $4K which is correct. With the new 4 GB EXE I get a drawdown of $50K and it's not consistent -- I get a slightly different result each time I run the script.

Cone or Eugene do you want to see if you can reproduce this? Also the equity curve looks very odd with weird spikes in it that are not there with the normal EXE. The system I'm using is a variation on HiLoLimit (converted to C#) but the same exact system runs fine in the old version of WL pro (not patched for 4 GB).

Dave

Uh oh. Just finished rebuilding the system with Windows 7 64 bit specifically for the purposes of expanding WLP memory and was about to patch WLP for 4GB... I guess I'll wait until the prognosis is clear. Thanks for the heads up, Dave.

It's also possible it's something unique to my PC (I can't see how -- then again I can't see how this could occur at all) so I'd suggest trying it (just make sure to backup the original EXE even though the patch tool should also back it up). You can always just rename back to the original EXE. Hey man, live dangerously! :P

Dave, thank you for reporting.

I don't want to jump the gun and thereby can't promise anything right now, but we're working on how to help you with this issue in some way.

Eugene is this something you guys can see as well? I understand this must be difficult to troubleshoot since it's not a bug per se, I'm guessing it must have to do with how some DLL calls are made (similar -- but NOT the same -- to the way PInvoke calls will fail on 64-bit platforms if you use an int32 and not an IntPtr). If I get time later I'm going to ask the guy from NTCore, if you see his site he seems to know just about everything there is to know about .net exes.

Since we're on the subject of system issues, let me ask this --

On my old Win XP system every now and then on WLP close Windows would show a popup indicating that the application crashed/caused system error (forgot the exact wording). I attributed it to the specifics of my system configuration. As I've mentioned earlier in this thread, yesterday I finished building a new system with a new CPU/motherboard/Windows version (7, x64) and everything... Well, the system case and the PSU are still the same, I guess. After copying my strategies to the new fresh WLP install on the next exit I get the same "application crashed" message again

CODE:
Please log in to see this code.

Is it me doing something wrong? Anybody else is experiencing the same issues?

Yes, we've seen it too, bug is logged, but considering that it occurs when closing WLP, there hasn't been much priority given to it.

QUOTE:
Eugene is this something you guys can see as well?

Can't help with that, my machine's got less chips than required.

But wait a little while, maybe we'll have some success in solving it for you.

Was there any resolution on NTCore issue by any chance?

Sorry, no.

Effects of applying NTCore utility --

Equity curve before patching


The same equity curve after patching


Any chance to address it in the near future? Without it there's no way to run SetTimeOfDayPriority or any intraday strategy @ 5 minutes scale or lower for more than 100 symbols x 1 year.

Andrew,

As mentioned in the Wiki FAQ, this utility is only suitable for x64 revisions of Windows. Are you sure you have one (asking because your latest ticket indicates the opposite)?

Yes, I've got a new desktop with Windows 7 Pro 64 bit several weeks ago. The old tickets have been submitted when I still had an old 32 bit XP box.

Unfortunately, enabling the LARGEADDRESSAWARE flag (that's what the utility does) seems to have a pretty nasty drawback. So we had to remove the mention of NTCore's utility from the Wiki. Thank you for the heads-up.

Once Fidelity dismisses the 32-bit FidelityServer, WLP should become a true x64 app. Something like this is planned.

Just for reference that was the same thing I saw. Very strange. I did email the guy who wrote the utility at NTCore and he had no clue why it would happen. And if you read some of his postings he really knows his way around windows, so it must be something pretty obscure.

Are there plans to support the 32 bit static adapters (such as metastock) in the 64 bit versions of WLD/WLP in the future? I believe I read this someplace but I'm not finding it now.

Dave

Found this posting:

https://connect.microsoft.com/VisualStudio/feedback/details/387385/marking-an-exe-with-largeaddressaware-on-x64-can-cause-virtualmemorysize64-to-return-negative-values

I wonder if this is part of the problem. Not that it matters -- there's no solution posted there.

Just remember it could always be worse -- I use Pinnacle Data for one of my futures data sources and their download/build program is 16 bit, so I need to run it in a VM as it won't run on 64 bit windows.

The developer once mentioned that based on what he read, enabling the LARGEADDRESSAWARE flag can result in a loss of stability. As we see now, one have to be really careful when playing with this flag.

QUOTE:
Are there plans to support the 32 bit static adapters (such as metastock) in the 64 bit versions of WLD/WLP in the future?

Was that a question to Microsoft? :) They tell us that 64-bit processes cannot load 32-bit DLLs, and 32-bit processes cannot load 64-bit DLLs.

The MetaLib 5.0 DLL, used by the Metastock provider, is a 32-bit C++ DLL which can't be loaded in a 64-bit environment. Although the Metastock/Computrac file format definition can be found (e.g. here and here) and theoretically, could be used directly in C# bypassing the Metalib, these are pretty outdated definitions that doesn't include newer MS format revisions.

I might be speaking out of turn here, but wouldn't it make sense to wrap those nasty dlls into exe/windows services and expose all methods and functions we need externally through a web service? Or open a local port and pump the binary data through? I would even say pipes but I'm not sure if they have pipes in Windows :).

I actually asked the guy from metalib and he said he has no plans to support 64 bit. So yes I was thinking more along the lines of what Andrew is talking about, basically putting them into a 32 bit hosting process and using some kind of interprocess communications (.net remoting or other such as DCOM). Something similar could also be used for the fidelity server if they decide to leave that 32 bit until they publish the API (which we all know will be released any day now ;P).

Thank you guys for these creative suggestions. Robert, what do you say?

QUOTE:
I would even say pipes but I'm not sure if they have pipes in Windows :).

Yes, named pipes have always existed in Windows. There seem to be quite a lot of links on using pipes in .NET applications.

Fidelity server will be re-written for 64-bit, mid year release.

If the question is about Metastock, we're probably not going to take the time to support a 40-year old, suboptimal data format for 64-bit. That's not definitive, but if we run out of other things to do, we can come back to it.