fx8000 wrote:Hi MrLong,

Many thanks for the new version.

I can see that many others are running the new version. I am quite puzzled why each time I load the ea, the Empty4 terminal just shuts itself straight away. No problem with previous versions.

I have loaded the ea, dll and mqh files as instructed on page one. Tried downloading the ea, dll and mqh files again today, same results.

I have tried to load it on demos for Alpari, Cowboy IBFX, FXCM -- with the same results. Empty4 Build 482.

My laptop is running windows vista home. Is it a windows problem ?

It is very odd.

I am still running v2.00 on demo with variable results

peter

simplex wrote:
I also faced frequent crashes of 2.01b on my rather weak test machine (single core, 1.5 GB RAM, Win7).

Commenting out the code that defines the CLOSE buttons did it. Running stable now, but very cpu consuming. Commenting out the CHART buttons as well leads to a significantly lower cpu consumption, but I wouldn't like to miss them! It's ok for me if that thing is stable.

BTW: I don't face similar problems on my quad core development machine. So I consider buying a somewhat stronger test machine anyway.

simplex

	for (k = 0; k < BUTTON_MAX; k++) {
		if (guiIsClicked(hwnd, buttonOpenChart[k]))
			ChartWindow(Pairs[k], PERIOD_H4);
	}

	for (k = 0; k < BUTTON_MAX; k++) {
		if(RunningTrades(Pairs[k]) ==0)
			guiEnable( hwnd, buttonCloseTrade[k],false);
		if (guiIsClicked(hwnd, buttonCloseTrade[k])) {
			if (MessageBox(Pairs[k]+", Close this trade?    ",
			               "Close Trade", MB_YESNO | MB_ICONQUESTION) != IDYES)
				return(1);
			CloseTrades(Pairs[k], maxSlippage(), MagicNumber);
		}

	}

dietcoke wrote:

simplex wrote:
I also faced frequent crashes of 2.01b on my rather weak test machine (single core, 1.5 GB RAM, Win7).

Commenting out the code that defines the CLOSE buttons did it. Running stable now, but very cpu consuming. Commenting out the CHART buttons as well leads to a significantly lower cpu consumption, but I wouldn't like to miss them! It's ok for me if that thing is stable.

BTW: I don't face similar problems on my quad core development machine. So I consider buying a somewhat stronger test machine anyway.

simplex

Code: Select all

	for (k = 0; k < BUTTON_MAX; k++) {
		if (guiIsClicked(hwnd, buttonOpenChart[k]))
			ChartWindow(Pairs[k], PERIOD_H4);
	}

	for (k = 0; k < BUTTON_MAX; k++) {
		if(RunningTrades(Pairs[k]) ==0)
			guiEnable( hwnd, buttonCloseTrade[k],false);
		if (guiIsClicked(hwnd, buttonCloseTrade[k])) {
			if (MessageBox(Pairs[k]+", Close this trade?    ",
			               "Close Trade", MB_YESNO | MB_ICONQUESTION) != IDYES)
				return(1);
			CloseTrades(Pairs[k], maxSlippage(), MagicNumber);
		}

	}

To me, this is the suspect piece of code in start.

1) I think that using BUTTON_MAX here is wrong. The number of chart buttons is defined when they are created as the number of pairs. Using BUTTON_MAX results in too many passes through the button check code.
The button check code should be moved into the main loop and the buttons associated with each pair should be checked at that time using the loop index (i) to access the two button arrays (buttonCloseTrade and buttonOpenChart)

2) Using guiIsEnabled as an enabled check prior to actually attempting to enable/disable a button should also reduce cpu usage.

dietcoke wrote:

simplex wrote:
I also faced frequent crashes of 2.01b on my rather weak test machine (single core, 1.5 GB RAM, Win7).

Commenting out the code that defines the CLOSE buttons did it. Running stable now, but very cpu consuming. Commenting out the CHART buttons as well leads to a significantly lower cpu consumption, but I wouldn't like to miss them! It's ok for me if that thing is stable.

BTW: I don't face similar problems on my quad core development machine. So I consider buying a somewhat stronger test machine anyway.

simplex

Code: Select all

	for (k = 0; k < BUTTON_MAX; k++) {
		if (guiIsClicked(hwnd, buttonOpenChart[k]))
			ChartWindow(Pairs[k], PERIOD_H4);
	}

	for (k = 0; k < BUTTON_MAX; k++) {
		if(RunningTrades(Pairs[k]) ==0)
			guiEnable( hwnd, buttonCloseTrade[k],false);
		if (guiIsClicked(hwnd, buttonCloseTrade[k])) {
			if (MessageBox(Pairs[k]+", Close this trade?    ",
			               "Close Trade", MB_YESNO | MB_ICONQUESTION) != IDYES)
				return(1);
			CloseTrades(Pairs[k], maxSlippage(), MagicNumber);
		}

	}

To me, this is the suspect piece of code in start.

1) I think that using BUTTON_MAX here is wrong. The number of chart buttons is defined when they are created as the number of pairs. Using BUTTON_MAX results in too many passes through the button check code.
The button check code should be moved into the main loop and the buttons associated with each pair should be checked at that time using the loop index (i) to access the two button arrays (buttonCloseTrade and buttonOpenChart)

2) Using guiIsEnabled as an enabled check prior to actually attempting to enable/disable a button should also reduce cpu usage.

Wkcfx wrote:

TallCoolOne wrote:

slipshod wrote:TCO, as currently coded that may not work well, as there's no check on either RSI or AO to look for a movement contrary to the current price direction to indicate that it wants to bounce. You could end up just entering in the face of a plunge that doesn't stop, whereas pending orders on a pivot require the price to show evidence that it may want to turn and resume the original trend. Of course that turn could end the moment you enter and resume a counter-trend plunge or even reversal, but that's life

One thing I do find odd though is the entry on pivots, when they can often act as price points where the market stops and reverses. I'd much rather see entries halfway between the pivots, on the basis that if its reached past the previous pivot line that far the chances are it'll continue on at least as far as the next one.

Hi SlipShod,

It just seems funny to me. We use AO/RSI and/or Stoch to determine if we have a good possible setup only to wait till prices goes higher to a point where price like to reverse. So now we have DD and we have to wait for price to go back up thru the S/R level that it already visited when or pending order got triggered and now go beyond that level to have have a trade start to win, when we could have opened the trade earlier and just take profit at the S/R level You could always open another trade at the S/R level. I just see us wasting a lot of price movement to confirm more price movement, when we could already be in the trade making pips. AO and RSI has shown that we should have a good setup....sooo... Just my 2 cents. Thanks!

And really that looks like what Andy is talking about...kinda....to avoid DD. He will use the first dummy order to see if it would have triggered the pending....wait for it to back down. then trigger a real order once the virtual DD is realized. I don't know....i see it both ways. I guess i could hack up the the EA and send Buystops and Sell Stops instead of Pendings and see what happens. Let me noodle on it. Maybe Andy just had the right idea.

Hi Guys

If memory servers, the original NB 10:4 rules were to set a pending in the direction of the "240 trend" and on the "240 trend friendly side" of a pivot point especially when entering on a retrace. The idea being to avoid entering the wrong way in a true reversal, and not to try to "call" the extent of a retrace but rather to wait and enter in the direction of the trend when the retrace is over and trend resumes. I believe that is a basic premise of the EA.
Or have I missed the fundamental points?

The difference being that NBob trades manually and is continually inputting his logic and experience, outside stimuli, news etc. This EA may evolve to that level for sure, especially if the production rate continues at this pace, but until it does it will need operator input imho. At this point we have many many fantastic trade elements, signals, entries, exits, mm etc. and all interactively working about 90% -100%.


My test of v2.00 and v2.01a for last week is below.
Aplari UK Demo, OOTB, hands off.
the "useSymbolTrailPercent" seems to be working very well.
Notice the monthly numbers suck! the v1.09 got it's "nickers in a knot" after the BOJ original announcement but was left hands off to see how it handled the situation....

my 2 cents.. and my hat off to Andy and the team!

Bill

simplex wrote:

fx8000 wrote:Hi MrLong,

Many thanks for the new version.

I can see that many others are running the new version. I am quite puzzled why each time I load the ea, the Empty4 terminal just shuts itself straight away. No problem with previous versions.

I have loaded the ea, dll and mqh files as instructed on page one. Tried downloading the ea, dll and mqh files again today, same results.

I have tried to load it on demos for Alpari, Cowboy IBFX, FXCM -- with the same results. Empty4 Build 482.

My laptop is running windows vista home. Is it a windows problem ?

It is very odd.

I am still running v2.00 on demo with variable results

peter

Hi Peter,

I also faced frequent crashes of 2.01b on my rather weak test machine (single core, 1.5 GB RAM, Win7).

Commenting out the code that defines the CLOSE buttons did it. Running stable now, but very cpu consuming. Commenting out the CHART buttons as well leads to a significantly lower cpu consumption, but I wouldn't like to miss them! It's ok for me if that thing is stable.

BTW: I don't face similar problems on my quad core development machine. So I consider buying a somewhat stronger test machine anyway.

simplex