תחומים - פורום חרדי מקצועי

אחרי שם הפרמטר כותבים = ואח"כ את הערך במידה ולא הוכנס הפרמטר הזה.
קוראים לזה Optional Parmeter חידוש של C# 4 נדמה לי.

פורסם במקור בפורום CODE613 ב22/07/2013 18:29 (+03:00)

@magicode

אתה יכול לחפש בתוך התוכן של כל הקבצים במחשב עם התוכנה הזאת.

http://www.nirsoft.net/utils/search_my_files.html

תחפש את השם של הקובץ האחרון או את חלקו. ותראה האם זה מביא לך את הקובץ הרלוונטי.

בלי קשר לנושא, התוכנה ממש מוצלחת ושימושית מאוד!
תודה רבה!

פורסם במקור בפורום CODE613 ב22/07/2013 14:04 (+03:00)

לא האפליקציה מטפלת ברשימה הזו, אלא Windows 7 ומעלה ע"פ בקשתה.
(מידי דברנו במעלות WPF, אז עושים את זה שם עם שורות XAML בודדות ללא קוד, אבל אף אחד פה לא כותב תוכנות שפותחות קבצים מן הסתם...)
איפה הWindows שומר את הרשימה? אז Windows נוהג לשמור הכל ברגיסטרי, לכאורה בדיוק איפה שארכיטקט הביא.
זה שמחקת וזה הוסיף להופיע, אני סבור שזה ייעלם אחרי שתדליק את המחשב מחדש. ואם כן באמת, זה לא עוזר לך.

פורסם במקור בפורום CODE613 ב21/07/2013 13:53 (+03:00)

[u:2o9o2tow][size=150:2o9o2tow]5.MulticastDelegate, וסיום המדריך [/u:2o9o2tow][/size:2o9o2tow]
הDelegate בדוט נט הם Multicast כלומר נציג אחד יכול להכיל הפנייה להרבה מתודות.
הנה דוגמה, במקרה זה יודפס פעמיים 123.

public Example()
{
    MethodContainer i = MyMethod;
    i = i + MyMethod;
    i();
}

void MyMethod() { Console.WriteLine("123"); }

אפשר להשתמש גם באופרטור המוכר +=, וגם ב-= להסיר מתודה כל שהיא, ממכלול המתודות. האופרטורים האלו עובדים גם כשהאובייקט ריק.
שימו לב שהדוגמה עסקה במתודת void.
במקרה של מתודה שמחזירה ערך זה חסר טעם, וזה מחזיר את הערך של הפונקציה האחרונה שהוכנסה.

טוב, סיימנו מדריך על נציגים, בע"ה מדריך הבא יהיה על אירועים.

פורסם במקור בפורום CODE613 ב05/02/2014 15:25 (+02:00)

[u:1nxlzsw8][size=150:1nxlzsw8]4. הצבה בדלגייט בצורה הצהרתית[/u:1nxlzsw8][/size:1nxlzsw8]
נחזור לדוגמה ראשונה היה שמה כזה קוד:

delegate void MethodContainer();

public Example()
{
    MethodContainer i = new MethodContainer(Write123);
    i(); 
}
 
public void Write123()
{
    Console.WriteLine("123");
}

ההצבה נעשתה ע"י בנאי שמקבל כפרמטר שם של מתודה.
כעת שימו לב, לא צריך בכלל בנאי. למה? כי שם מתודה הוא עצמו "ליטרל".

מה זה ליטרל?? סטרינג לדוגמה יכול להופיע כפי שהוא בקוד, בלי צורך בNEW בהצבתו. איך? מוקף במרכאות כפולות. קוראים לזה ליטרל (מאחורי הקלעים נוצר אובייקט עם NEW שמכיל אותו!).
אותו הדבר Char יכול להופיע כמו שהוא מוקף במרכאה בודדת (בVB גם במרכאות כפולות שאחריהם מייד שמים את האות c). לעמות זאת בDateTime ובאלפי מחלקות אחרות, אין ליטרל. אין שום אפשרות ליצור עצם בקוד (קוד הצהרתי) בלי לעשות זאת מפורשות (קוד פונקציונלי). אגב, בVB יש כן ליטרל לתאריך ע"י תאריך בפורמט MM\DD\YYYY מוקף בסולמיות, אנשי C# תקנאו אבל לעניין הנושא המדובר זה להיפך: בVB שם מתודה איננה ליטרל...

וזה אומר שכשמופיע בקוד שם מתודה, הקומפיילר מתרגם זאת לאובייקט מסוג delegate. אתם עלולים לשאול איזה delegate שהרי הצהרת delegate חייבת לכלול פרמטרים נדרשים וערך מוחזר. התשובה היא שהקומפיילר מסיק את סוג הdelegate לפי חתימת המתודה שנקבנו בשמה.
הנה המסקנות בקוד, בשלב הראשון נסיק שאפשר לכתוב ככה:

public delegate void MethodContainer();

public Example()
{
    MethodContainer i = MyMethod;
    i();
}

הנה, לא השתמשנו בכלל בNEW.

פורסם במקור בפורום CODE613 ב30/01/2014 14:41 (+02:00)

[u:2qcedb8a][size=150:2qcedb8a]3. דוגמה נוספת[/u:2qcedb8a][/size:2qcedb8a]
הדוגמה האחרונה הייתה על Delegate עבוד מתודה ללא פרמטרים וללא ערך מוחזר. כעת נראה דוגמה זה יש ערך מתקבל וערך מוחזר:
נניח אנחנו מפתחים פקד טקסטבוקס משוכלל עם אפשרויות מתקדמות.
אחת השכלולים שעשינו בו זה ולידציה, הפקד נניח מסמן באדום נתונים לא תקפים.
אבל מהו נתון לא תקף? אם זה ת.ז. יש נוסחה אחת, אם זה משהו אחר יש נוסחאות אחרות.
ואנחנו כמובן "משאירים את זה פתוח" למתכנת (זה ע"פ רוב אנחנו בעצמנו...) שישתמש בפקד הזה, שהוא יקבע לפי השימוש והעניין מה הנוסחה.
איך הוא יקבע?
עם דלגייט זה מאוד פשוט. במחלקה יהיה קוד דומה לזה:

//הצהרה סוג
public delegate bool ValidUserInput(string message);

//הצהרת מופע - בינתיים הוא ריק
public ValidUserInput FunctionToValidate { get; set; }

//פוקנציה שמופעלת מתי שצריל לבדוק את קלט המשתמש, אם הקלט לא תקני היא צובעת את הפקד באדום
void vaildateInput()
{
    if (FunctionToValidate != null)
        if (FunctionToValidate(faturedTextBox.Text) == false )
            faturedTextBox.Background = Red;
}

בצד המשתמש, כלומר מי שישתמש במחלקתנו, ושוב ושוב אדגיש שזה כולל אותנו (כעובדים נכון וממדרים פרוייקטים)
אז המשתמש הזה משתמש בפקד בכל מיני מקומות לכל מיני מטרות. פעם לחשבון בנק, פעם לת.ז. וכו'.
האחריות על הפוקנציה לבדיקת התקינות בהכרח מוטלת עליו, רק הוא יודע מתי לעשות איזה אימות (מילים נרדפות: אימות, תיקוף, ולידציה).
אז נניח מקרה שהוא משתמש בפקד שלנו בשביל להציג 4 ספרות אחרונות של מס' אשראי, והנה הפונקציה שהוא הכין:

//פונקציה לאימות 4 ספרות אחרונות של כרטיס אשראי
bool Check4DigitNum(string str)
{
    int ParserValue;
    return int.TryParse(str, out ParserValue) && ParserValue > 0 && ParserValue < 10000; 
}

הוא צריך רק להגדיר את הדלגייט של המחלקה, שיכיל את הפונקציה שלנו:

FaturedTextBox1.FunctionToValidate = new FaturedTextBox.ValidUserInput(Check4DigitNum);

פורסם במקור בפורום CODE613 ב22/01/2014 16:30 (+02:00)

[u:2eqoffeb][size=150:2eqoffeb]2. דוגמה בסיסית לנציג[/u:2eqoffeb][/size:2eqoffeb]
נניח אנו מפתחים מחלקה (למשל מחלקה שמשדרת לשב"א או כל פעולה ארוכה בסגנון).
המחלקה היא DLL דוטנטי טהור. ללא כל ייצוג גרפי.
אנו כותבי המחלקה, כותבים פרוצדורה ארוכה, שמורכבת מהרבה חלקים. מידי פעם אנו משחררים חיווי על המצב הנוכחי
(כמו: "מעבד נתונים...", "מבצע אימות...", "משדר...", "שודר בהצלחה!", "מחכה לתשובה...").
השאלה איפה להציג את החיווי הזה?

אז מאוד מתאים להשתמש בDelegate:

public delegate void StatusMessage(string message);

/// <param name="messageHandel">נציג של מתודה לטיפול בהודעות הסטטוס</param>
public void GoSendData(DataTable data, StatusMessage messageHandel)
{
    //....פעולות
    messageHandel("כעת אוכל דגים...");
    //....פעולות
    messageHandel("כל הדגים נאכלו. מתכונן למנה הבאה...");
    //....
}

כעת הנה קוד בו אנחנו או מתכנת שקנה/קיבל מאיתנו את המחלקה דלעיל כDLL, משמשים בה, ומציגים את ההודעות במקום שנראה לנכון, במקרה זה אפילקציית וינדוס ואנו רוצים שההודעות יופיעו בליסט בוקס:

public UseClass()
{
    var shidur = new ShidurShva();
    shidur.GoSendData(dt, new ShidurShva.StatusMessage(ShowMessage));
}

public void ShowMessage(string message)
{
    //שם במקרה זה את הודעת המצב בליסט בוקס
    ListBoxLog.Items.Add(message);
}

[size=85:2eqoffeb][u:2eqoffeb]במאמר המוסגר:[/u:2eqoffeb]

1. **הדוגמה הציגה מצוקה שצריכה פיתרון. המצוקה לא לגמרי נכונה כי האמת שהכי פשוט זה לכתוב לקונסול (Console.WriteLine) והמתכנת שיעשה שימוש במחלקה יכול להפנות את הפלט לאיפה שירצה, אבל למען יופי הדוגמה נניח לא הייתה כזאת מחלקה כלל.
2. מתכנתים רבים יחשבו "זה ממש אירוע קלאסי" ויתהו למה לא ליצור אירוע של התקדמות עם ארוגמנט למצב (או מאפיין סטרינג עם המצב האחרון ואירוע שמתריע על שינויו). אז נא לזכור שאירוע זה דלגייט בשינוי אדרת... נדבר על כך בהמשך.**
   [/size:2eqoffeb]

פורסם במקור בפורום CODE613 ב19/01/2014 13:46 (+02:00)

[u:1k4ychdj][size=150:1k4ychdj]1. רקע[/u:1k4ychdj][/size:1k4ychdj]
פירוש המילה היא נציג. כלומר במקום לבוא במגע עם המתודה, יש לנו אובייקט שמייצג אותה, אפשר "לומר לו", והוא כבר יפעיל את המתודה המקורית.
נגיד יש לנו מתודה שמדפיסה על המסך "123"
אז כשאנו מציבים אותה ב"נציג" היינו הDelegate, אז יש לנו פונקציונליות ביד. אנו יכולים להכניס אותה למשתנה, למאפיין, לשלוח את זה כפרמטר לפונקציה והכל תחת הסוג ששמו Delegate.

אז הנה הדגמה לdelegate בצורתו הבסיסית, בשלוש צעדים:
א. מצהירים על הdelegate (כי כל Delegate נבדל מאחר בפרמטרים שהוא מקבל והטיפוס המוחזר).
ב. מאכלסים אותו - יוצרים מופע ממנו ובבנאי שלו שמים את שם המתודה שלנו.
ג. קוראים אליו משתמשים בו במקום במתודה המקורית

class Example
{
    //הצהרה על שמו+מה הוא מחזיר+מה הוא מקבל (במקרה זה כלום).
    delegate void MethodContainer();

    public Example()
    {
        //יצירת מופע מהדלגייט. בבנאי מעבירים כפרמטר שם של מתודה, אותה הוא "ייצג".
        MethodContainer i = new MethodContainer(Write123);
        //שימוש בו השקול לקריאה ישירה למתודה שהוא מחזיק
        i();
    }

    public void Write123()
    {
        Console.WriteLine("123");
    }
}

בהודעה הבאה אדגים בע"ה שימושים בDelegate.

פורסם במקור בפורום CODE613 ב18/07/2013 14:41 (+03:00)

הרעיון של ספירת האפסים לכאורה נכון ומהיר יותר מהרעיונות האחרים.

מה שכתבת
@רחמים

אלא צריך לעבור כל כל הפיקסילים או על כמות מדגמית ולראות כמה פעמים הצבע משתנה מפיקסיל לפיקסיל, כלומר האם רוב הפעמים פיקסיל נתון שווה בצבעו לפיקסיל השכן, או שרוב הפעמים פקסילים שכנים שונים זה מזה בצבעם.

זה לא בדיוק מה שהצעתי לעיל?

פורסם במקור בפורום CODE613 ב21/07/2013 13:58 (+03:00)

@רחמים

@magicode

עכשיו אני מקבל את זה בצורת מערך של 64 אברים שכל אבר מכיל ערך לדוגמא מ 0 עד 1. כל אבר מיצג בתמונה קו ואם הוא 100 הקו מופיע עד למעלה ואם הוא 0 הוא לא מופיע בכלל ואם הוא 0.5 הוא מופיע חצי וכן הלאה.

איך אני יכול לקבוע כלל שיהיה אפשר לפי המערך להבדיל בין תמונה מצולמת לתמונה מצויירת.

חשב את הממוצע של כל האברים במערך אם הממוצע מעל 50 בוודאי שזה מצולם ואם פחות מ 10 בוודאי שזה ציור.
וכמובן ממוצע זה חיבור של כל האיברים לחלק במספר האיברים.

שים לב, ממוצע בכל מקרה מיותר לחשב, כי ממוצע נדרש רק כשמס' האיברים משתנה, פה הוא קבוע (64) ומספיק סיכום.
שנית, אני לא הייתי בטוח שאמנם ישנה חוקיות שההיסטוגרמה של תמונה תכיל יותר בס"ה, אבל זה במת מה שקורה בדוגמאות שהוא הביא.

פורסם במקור בפורום CODE613 ב21/07/2013 12:18 (+03:00)

@magicode

STDEV.P זה נוסחה שקיימת באקסל ?

2010..

בקודמים יש STDEVP.

פורסם במקור בפורום CODE613 ב18/07/2013 12:37 (+03:00)

איזה מאתגר הנושא

אני מתמקד בשאלתך ולא בהקדמה:
לפי מה שאני רואה בדוגמאות, אז הרעיון הוא סטיית תקן גבוהה (מעל 0.2 נגיד).
אולי בשביל ביצועים עדיף לבדוק סטיית תקן מדגמית.

הנה דוגמא מאקסל, שתי טורים, הימיני כאילו ציור והשמאלי תמונה:
0.80 0.20
0.00 0.25
0.00 0.30
0.30 0.35
0.00 0.40
0.00 0.35
0.40 0.30
0.00 0.25
0.00 0.20
0.00 0.15

התוצאה של הנוסחה STDEV.P (סטיית התקן מלאה לא מדגמית)
0.257875939 לטור הימני.
0.075 לטור השמאלי.

פורסם במקור בפורום CODE613 ב18/07/2013 11:15 (+03:00)

אני מתכנת בדוט נט משנת 2002 בערך.
כמובן שאז בWinForms.
עברתי לWPF לגמרי רק לפני כמה חודשים.
היה לי קשה לעבור, לא מצאתי סיבה, ולא אהבתי את הבלגן שWPF עושה מכל עניין.
אהבתי את WinForms שהכל קוד, והכל ידוע.
אבל, עברתי.

רחמים, אין לך סיבה למהר, אבל אם יום אחד נמאס לך מWinForms,
אתה תקפוץ לWPF.

מה WPF נותן?
אז "ארכיטקט" נתן הרבה סיבות.
מבחינתי הMVVM הוא משני בחשיבותו (אני לא הולך בדרך זו לצערי)
מה שמשך אותי זה קלות העיצוב, הביינדינג, ומעל הכל הItemTemlate לסוגיהם.

עכשיו להפך מה החסרונות של WPF?
אז השאלה על הDebug של הXAML זה צליפה בנקודה רגישה, זה באמת טיפה מסובך יותר. אבל לא רציני.
במיוחד כשיש פורום שעוזרים בכל בעיה...

השאלה למה הפקדים צריכים להיות בתוך Grid ולא ישירות בWindow היא שאלת "אורח".
כשתיכנס לעניינים תבין הרבה, א"א להבין במבט ראשון...
אבל עניינית התשובה היא בגלל שWindow הוא אלמנט מהקבוצה ContentControl שהם בעצם מקבלים אלמנט בן יחיד.
בשביל לקבל כמה אלמנטים ב"מיכל" אחד יש את Grid כמו עוד כמה דומים כל אחד וה"מומחיות" שלו.

פורסם במקור בפורום CODE613 ב18/07/2013 10:48 (+03:00)

@ClickOne

בעיקרון LINQ מתחלק לכמה חלקים:
אם השאילתא פשוטה, כמו SELECT, הוא ממיר את השאילתא למחרוזת SQL, מריץ את זה בשרת, ומציף את הליסט בנתונים.
אם השאילתא יותר מורכבת, הוא "מנסה" להמיר אותה לפרוצדורה של SQL, מריץ אותה בשרת וכו'
ואם עשינו בשאילתא הפניות לפונקציות פנימיות אז:
[list:uzb1e9br][:uzb1e9br]אם הוא יכול להמיר גם את הפונקציה ההיא הוא ממיר אותה[/uzb1e9br]
[:uzb1e9br]אם הוא לא יכול, הוא קורה לכל הרשומות ומריץ את כל התהליך.[/uzb1e9br][/list:u:uzb1e9br]
איך אני יודע?
יש כלי מעקב על השרת שמראה את כל הבקשות שרצות.
בעז"ה אני ישתדל להראות כמה דוגמאות בקרוב.

אגב אקסס עם ODBC מתנהל בערך באותה הדרך, ומכאן האיטיות שלו עם ODBC.

שלום!
אתה מדבר על LinqToSql, אנחנו דיברנו על LINQ רגיל, ToObject.
אתה משתמש הרבה עם LinqToSql? שווה? אני מעולם לא ניסיתי.
מיקרוספט זנחו אותו לטובת Entity, ולEntity לא הצלחתי להתחבר, אז אני עובד עם ADO הרגיל.

פורסם במקור בפורום CODE613 ב30/12/2013 10:28 (+02:00)

הנה בדיקות כאלו בדיוק מהרשת:
לרעת לינק:
http://ox.no/posts/linq-vs-loop-a-performance-test
http://social.msdn.microsoft.com/Forums/en-US/facff412-118a-4a80-867a-66503463a638/measure-the-performance-of-a-linq-sort
http://martin.podval.eu/2010/10/c-sharp-linq-or-foreach-performance.html
http://www.alexyork.net/blog/2008/09/14/performance-of-foreach-loops-vs-linq/
http://www.codeproject.com/Articles/21934/LINQ-Performance-Test-My-First-Visual-Studio-2008http://www.dotnetscraps.com/dotnetscraps/post/linq-performance-part-1-linq-to-collection.aspx

בלוג שמדבר הרבה על זה:
http://msmvps.com/blogs/jon_skeet/default.aspx

יש הרבה כללים שנבנו מתצפיות איך כדאי לבנות את השאילתה, אבל אני חושב שהם לא כללי ברזל.
כי המסקנה היא מתצפיות, שיכולים להשתנות עקב שיפורים במנוע בכל גירסת דוט נט.

אבל יש כללים הגיוניים.
לדוגמא לבדוק אם רשימה ריקה, עדיף לבדוק ע"י פונקציית Any שמחזירה לא במקרה ריק מאשר להשוות את Count לאפס.
זה ברור כשמש, בפרט כאשר התוצאה היא שיש איברים אבל אפי' במקרה שאין.
אולי נבנה רשימה של כאלה המלצות.

פורסם במקור בפורום CODE613 ב18/07/2013 18:23 (+03:00)

@ארכיטקט

אני לא יודע איך לבדוק זאת.

יש לי רעיון פשוט, תממש את שלושת האפשרויות, תפעיל טיימר שיקבע כמה זמן לקחה השאילתה.
אחר כך לממש את זה עם לינק ולהשוות ביצועים.
תעשה את זה על מיליון או עשר מיליון איברים, ותראה את ההפרשים בבירור.
מעניין אותי לדעת תוצאות.
תעדכן....

בעבר בדקתי ככה. כל מיני שאלות שהיה לי.
אבל זה דרך מפותלת ומרגיזה.
תזכור שאם היה לי כח לכתוב כ"כ הרבה קוד, אז לינק היה מיותר בשבילי
יש כלים חינמיים לזה אבל לא הצלחתי כ"כ לעבוד איתם.

פורסם במקור בפורום CODE613 ב18/07/2013 16:56 (+03:00)

ביצועים בLinq זו שאלה כבדת משקל.
בעצם לכאורה אנו שוב זונחים את שקלולי הביצועים לטובת נוחות.
אז דבר ראשון, זו החלטה נבונה ברוב המקרים.
דבר שני, ברוב המקרים Linq יעיל בבירור.

האם אפשר לבחון/לשלוט על זה? לא לגמרי.
הגישה צריכה להיות מה ההינו עושים ללא לינק. הלינק אמור לעשות בדיוק אותו הדבר שהיינו עושים, אבל "במקומנו".
אם יש לנו מערך מספרים שלמים, ואנו רוצים רק את הזוגיים.
איך היינו עושים ללא לינק? יוצרים ליסט, עוברים בלולאה על המערך, ובהתקיים התנאי (איבר לחלק לשתיים שווה 0) מוסיפים לליסט.
זהו זה. אז לינק עושה את זה ממש ככה.

לפעמים אפשר ממש לתהות ביכולתיו של הlinq.
לדוגמה יש לנו מערך מספרים שלמים, ואנו רוצים לקחת את כל הגדולים ממאה, ובצורה ממויינת.
איך היינו עושים ללא לינק?
[u:37lq31qk]הדרך הפשוטה:[/u:37lq31qk]
א. ממיינים ע"י Array.Sort.
ב. מתקדמים מהקצה התחתון בלולאה עד שמגיעים למאה, ומשמה מעתיקים את המערך.
[u:37lq31qk]או הרבה יותר טוב והרבה יותר נחות (מתאים לאנשי C++) [/u:37lq31qk]
למיין בעצמנו, ואז תוך כדי להשמיט איברים גדולים ממאה.

אז ללינק יש שלוש אפשרויות:
א. להיות טיפש מוחלט וקודם להסיר ואח"כ למיין.
ב. למיין ולהישען על המיון כדי לסנן נמוכים (בלתי סביר שלינק עושה כך, כי הוא לא יכול לדעת שיש קשר בין קובע המיון למהות התנאי).
ג. להיות חכם ולממש לבד את המיון, ותוך כדי להסיר נמוכים.

אז הנה דוגמא שלינק יכול להיות ממש יעיל כמו מתכנת טרחן מעולם הC++. או להיפך...
אני חושב שהוא אכן חכם ויעיל, אני לא יודע איך לבדוק זאת.
לקרוא IL לא כ"כ נעים לי, כלומר אני לא יודע...
ולראות ברפלקטור זה לא עוזר, כי הוא מציג שאילתת לינק...
בימים הקרובים אולי אכתוב מהו הרפלקטור הזה על הפתעות שהוא עשה לי לפעמים.

פורסם במקור בפורום CODE613 ב18/07/2013 11:38 (+03:00)

@שמואל

האם יש אפשרות של תנאי בטריגר
זאת אומרת כפי שיש מולטי טריגר שמקבל כמה קונדישינים
האם יש גם אפשרות לקבל כמה קונדישינים ובהתאם לכל קונדישין שיתן עיצוב אחר?
תודה

בא נשווה זאת לif בC#.

המבנה של if הוא כזה:
אם X = "כן" תעשה א
אם X = "לא" תעשה ב
אחרת (else) תעשה ג

אז בWPF נעשה ככה. בסטרים של הסטייל נעשה את ג',
ונוסיף שתי טריגרים, אחד למקרה "כן" עם עיצוב א, ואחד למקרה "לא" עם עיצוב ב.

ומה אם מקרה שאנו רוצים לדעת כן/לא על ביטוי לא שויוני; לדוגמה אם X גדול מ2?
אז א"א להשתמש עם טריגר.
בשביל זה עושים קונברטר, ואז "כורכים" (בינדינג) את העיצוב לX עם הקונברטר שיבדוק כל תנאי שבעולם ולפי זה יחזיר ערך מתאים לעיצוב.

פורסם במקור בפורום CODE613 ב18/07/2013 12:11 (+03:00)

הבעיה שאצלי זה עבוד גם במקטע הCellTemplate...
(הורדתי את הפקד, וחיקיתי כמעט עד לפרט האחרון את התנהגות הקוד שצירפת).
הרעיון של הEditing זה שהוא נכנס לפעולה רק אחרי דבל קליק. אבל אפשר לשנות ערכים גם ממצב CellTemplate רגיל.

מעניין איפה הבאג, אבל העיקר שעובד.

פורסם במקור בפורום CODE613 ב14/07/2013 22:28 (+03:00)

ניסיתי משהו דומה אצלי והכל עובד. מעניין מה קורה שמה.
(דוקא לי היו בעיות עם הביינדיגים).

אם את שמה את הקומבו מחוץ לדטהגריד אם אותם הגדרות בבינדינג, הכל דופק?
ולמה מחלקה יורשת בתוך UserControl ולא ישירות הכל במחלקה היורשת או ביוזר קונטרול?

פורסם במקור בפורום CODE613 ב11/07/2013 13:12 (+03:00)