XdXu EFS Help

[OpaBert]

Help !!!

Every time I try to use " reloadEFS(); " in my script it crashes eSignal. I thought " reloadEFS(); " would solve my problem but instead it actually kills eSignal.

I have a script that draws a ray from point A through point B.

Each time I get a new "B" I want the Ray to redraw.

Without " reloadEFS(); ",

In Bar RePlay Everything works. But,

In REAL TIME, Either it draws every possible Ray or only draws the last Ray and I have to MANUALLY do a Reload from the chart.

Any clues about what is going on?

Thanks, Opa.

[ACM]

Opa
As you have already had an opportunity to see for yourself ReloadEFS() is a very dangerous command and should be avoided if possible. There are probably other ways to resolve the issue you are having.
Post the efs and someone is likely to help
Alex

[gspiker]

Alex took the word right out of my mouth. reloadEFS() is very dangerous and you almost never have to use it.

I would only add, if you are only getting one ray and expecting more, one thing to verify is that you are giving each ray a unique tag (or not giving them any tag at all I belive is a valid option also).

If you are getting too many rays - there is some error in logic in the code I would think.

Garth

[OpaBert]

Chart & EFS

Here's what the chart looks like.

[OpaBert]

EFS for XdXu

Here's the EFS.

I would also like to eventually have the script connect each Xd to Xu to Xd to Xu .... etc point to help with elliot wave analysis.

This is what it would look like:

[OpaBert]

XdXu EFS Script

Needs to be tested in REAL TIME.

Seems to work in Bar Replay, but not RT.

Thanks in advance to anyone that can solve this!

Opa.

[gspiker]

It's a bit early in the morning here, but if I understand your EFS correctly then I think the problem is that you pop your arrays and draw your lines only when BarIndex == -1. BarIndex will only == -1 once and that is in historical mode. In RT mode this means you will never update the lines drawn or the arrays after the historical data has been processed.

I think you want the lines to update as new data comes in.

I have to run, but you might try using getBarState() and checking for BARSTATE_NEWBAR instead.

When I get back, if you haven't tried this I will try testing your script as is in TICK replay mode (and seeing if I see the same problems you did) and then changing it a bit to see if I can fix it.

Garth

[gspiker]

Opa,

I ran your EFS in TICK playback mode and saw what you were saying.

I made some changes so that it would work...BUT I'm not sure it is exactly what you wanted. There were a few options on how to do this, I I figured you would always want the last two points connected in RT mode, but only the very last two for historical.


Attached is the EFS.

[OpaBert]

XdXu EFS Help

Thanks "gspiker",

I see what you did, (results) but the Ray origin point is NOT automatically the prior Xd or Xu.

In the case of the Xd (d = down) Ray, when a new Xd point is identified the EFS then LOOKS BACK until it finds a prior Xd that has a value greater than the new (current) Xd. (If it can not find a higher prior Xd in the data available, no Ray is drawn.) It then draws the Ray from the higher Xd it found through the new Xd.

This criteria requires that an Xd Ray MUST always have a DOWN slope.

Similarly, the Xu (u = up) Ray MUST always have an UP slope.

The lookback was working when I manually did a reload.

Hope you can put it all together. I appreciate your assistance.

Opa.

[gspiker]

Hi,

OK, so let's run through an example:

Xd(barIndex) = value

a) Xd(-50) = 20
b) Xd(-42) = 23
c) Xd(-37) = 18
d) Xd(-20) = 22


OK, a gets hit first...nothing to do. b's value is greater than a, nothing to do. Now for c...do I draw ray a->c or ray b->c or both? I assume b->c only, correct?

Moving on d is greater than c, so no ray there, but c is less than b. Do I draw ray b->d?

In other words, do I:

1) Look back for all possible higher values (for Xd) and if found create as many rays as higher values?

2) Look back only to the last Xd and if it isn't higher ignore it?

or

3) Look back and draw a ray to only the nearest higher Xd?

I assume #3, but want to make sure.

Garth

[OpaBert]

XdXu EFS Help

Hi Garth,

Thanks for the review.

Yes, I think we are on track with #3. I attached a sample chart showing what the results should look like to meet the XdXu criteria.

Only ONE Xd And only ONE Xu Ray should be on a chart at any point in time.

The Ray will always be drawn through the LAST identified Xd or Xu point and will always originate from the "nearest prior" Xd or Xu that causes the Ray to slope correctly.

In the chart you notice there is an Xd and an Xu that is between the Rays origin and "through point". The "between" Xd and Xu were past by because using them would not result in a correct slope by the resulting Ray.

Hope my description does not confuse the issue and I'm looking forward to your EFS update.

Thanks again for the help.

Opa

[gspiker]

Opa,

An interesting case...what happens if there is no Xu lower than the current Xu on the chart? Do you just keep the last pair where there was a match?

Garth

[OpaBert]

XdXu EFS Help

Hi Garth,

If prior Xd or Xu data is not available to meet the slope criteria then NO ray is drawn.

Opa

[gspiker]

Opa,

Great! That's the tact I took. Attached is the latest version of the code. It worked great in tick playback mode. I think it does what you want.

Garth

[OpaBert]

XdXu EFS Help

Thanks Garth,

I'll try it in RT later this morning.

Opa