מדוע שני EA זהב עלולים לטפל באותה פקודה? בדיקת מספר קסם ב-MT4
הדגמה באמצעות תרחיש בחשבון דמו כיצד EA מסנן פקודות לפי סימבול ומספר קסם, וכיצד לאחר החלפת מספר להימנע ממצב שפוזיציות ישנות נותרות ללא ניהול.
מחבר: תומאס｜עבודה מעשית ב-MT4｜10 בנובמבר 2026
תקציר: כאשר בחשבון MT4 אחד מותקנות שתי מערכות EA זהב, אם הן משתמשות באותם תנאי זיהוי פקודות, ייתכן ששתיהן ישנו את Stop Loss של אותה פקודה בו-זמנית. בעת בדיקה יש לבחון תחילה את הסימבול ומספר הקסם של הפקודה, ולאחר מכן את התנאים שלפיהם הקוד בפועל מסנן. המספרים והפקודות המופיעים להלן הם הנחות לצורכי הוראה.
היכן נשמר מספר הקסם
OrderSend ב-MQL4 תומך בהעברת פרמטר magic. לאחר שהפקודה נבחרה בהצלחה, ניתן לקרוא את מזהה הפקודה באמצעות OrderMagicNumber. הוא מספק בסיס לסיווג עבור התוכנית. אילו פקודות בפועל יישנו או ייסגרו עדיין נקבע על ידי לוגיקת הסינון והביצוע של ה-EA עצמו. אם התוכנית עוברת על פקודות החשבון ובודקת רק את הסימבול, שתי מערכות EA זהב עשויות לטפל באותה קבוצת פקודות גם אם הוזנו להן מספרי קסם שונים.
בתרשים מונח כי אסטרטגיות A ו-B משתמשות בהתאמה ב-101 וב-202. A בוחרת פקודות אחת-אחת ממאגר הפקודות, בודקת תחילה את הסימבול בפועל ואחר כך את מספר הזיהוי. רק כאשר שני התנאים מתקיימים, הפקודה מועברת ללוגיקה הבאה לבדיקת סוג הפקודה והפעולות המותרות. כשל בבחירת פקודה יש לדלג עליה ולתעד שגיאה. לפני פעולות שינוי, מומלץ לבחור שוב את פקודת היעד, כדי להימנע משימוש בנתונים ישנים שהועתקו קודם לכן אל התוכנית.
אימות בשלושה שלבים בחשבון דמו
שלב ראשון: לתעד את הגרסה, פרמטרי הקלט, מחזור הגרף והשם המלא של הסימבול אצל הברוקר עבור שתי מערכות ה-EA. שם הזהב בחשבונות שונים עשוי לכלול סיומת. כאשר פורסים מספר מופעים על אותו סימבול, יש להבהיר גם אם הם מנוהלים באופן עצמאי או שמלכתחילה תוכננו לחלוק פקודות.
שלב שני: בחשבון דמו לגרום לכל מערכת EA ליצור פקודת בדיקה מזוהה, ובמקביל להכין פקודת בדיקה שאמורה להיות מוחרגת. ביומן יש לתעד לפחות את מספר הפקודה, הסימבול, מספר הקסם והפעולה שהתוכנית מתכוונת לבצע. לאחר מכן להפעיל פעולת ניהול מבוקרת אחת, למשל ניסיון לשנות את פקודת הבדיקה של אסטרטגיה A, ולבדוק אם פקודת אסטרטגיה B נשארת בערכה המקורי. מומלץ לאמת בנפרד פקודות ממתינות ופוזיציות שנסגרו, מכיוון שמאגר הפקודות עשוי לכלול את שני הסוגים, וכללי הטיפול בפועל בדרך כלל שונים.
שלב שלישי: לאחר הפעלה מחדש של הטרמינל או טעינה מחדש של ה-EA, לבדוק שוב. אם התוכנית זוכרת רק את רשימת הפקודות שנוצרה במהלך הריצה הנוכחית, ההתנהגות לאחר הפעלה מחדש עשויה להשתנות. ניתן לבדוק אם היא מזהה מחדש פקודות לפי התנאים שנקבעו, ואם כאשר אין פקודות מתאימות מתרחשת פעולה בלתי צפויה. המספרים משמשים רק לבידוד מסייע; אם בדיקת הסיכון הכולל ברמת החשבון קוראת בכוונה את כל הפוזיציות, יש לתעד אותה בנפרד מהרשאת השינוי בפועל של פקודות.
לפני החלפת המספר יש לטפל בפקודות הישנות
נניח שאסטרטגיה A פתחה בעבר פוזיציה עם 101, וכעת משנים ל-303. שינוי פרמטרי קלט בדרך כלל משפיע רק על הערכים שבהם משתמש הקוד בהמשך, ומספר הזיהוי של פקודות ישנות אינו עובר אוטומטית עם הגדרות הגרף. אם תנאי הניהול מתאימים רק ל-303, פקודות ה-101 המקוריות עלולות להידלג. לפני השינוי יש לרשום את הפקודות הישנות ואת אופן הטיפול המתוכנן, ולאחר מכן לאמת בסביבת דמו את ההפעלה מחדש ואת ההעברה. כאשר נתקלים ב-EA שגרסתו אינה ניתנת לבדיקה או שהיומן אינו מסביר את לוגיקת הסינון, יש להשהות שינויי ניהול אוטומטיים ולבדוק את ترتيب היציאה מהפוזיציות הקיימות. מעבר בבדיקת דמו מעיד רק על התרחיש שנבדק; שינויי מחירים אמיתיים, דחיית פקודות על ידי השרת וסליפג' עדיין דורשים הערכה נפרדת.
