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

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

ב. אין, אבל תוכל לעקוב אחרי מקור הנתונים במקרה של ObservableCollection.

פורסם במקור בפורום CODE613 ב29/04/2014 12:39 (+03:00)

מה מקור השורות של הDataGrid של המוצרים?

פורסם במקור בפורום CODE613 ב24/04/2014 19:46 (+03:00)

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

פורסם במקור בפורום CODE613 ב24/04/2014 19:59 (+03:00)

קודם כל, אני חייב לציין את העונג שעושה כזו שאלת איכות... תודה!

שים לב שהשוות את הבעיה שלך לשסנים של ווב. נו ואיך זה עובד שם? כמשתמש מסויים פונה פעם ראשונה הוא יוצר סשן בצד השרת, וע"י מאפיין timeout הוא מתפרק אחרי "נטישה ארוכה" - פרק זמן בהם אין פניה.
הבעיה שלך שאין לך צד שרת. יש לך אוסף קליינטים שעובדים ישירות מול SQL SERVER אז בעצם אין מי שינהל את השסנים, ובמחשבה שניה גם אין מי שיעשה עם המידע הזה משהו.

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

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

שים לב שייתכן שתרצה שאי פעילות בתוכנה תחשב גם היא ל"ניתוק", יש על זה "דיבורים" ברשת (למשל http://www.codeproject.com/KB/WPF/AutologoffWPF.aspx?msg=3238811)

פורסם במקור בפורום CODE613 ב24/04/2014 11:37 (+03:00)

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

פורסם במקור בפורום CODE613 ב10/04/2014 18:43 (+03:00)

RAISERROR, אם הבנתי אותך נכון.
ככה:

RAISERROR ('כאן אתה כותב מה בא לך', 1 , 0)

פורסם במקור בפורום CODE613 ב10/04/2014 18:38 (+03:00)

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

בקשר לנקודה שעוררת, אכן זה רחוק מלהיות מושלם. למעשה שווה לבדוק כאלו שכתבו משהו מושקע יותר או ללמוד ממעשיהם, כמו זה: http://www.codeproject.com/Articles/36516/WPF-Modal-Dialog, http://www.codeproject.com/Tips/563144/WPF-Dialog-MessageBox-Manager

פורסם במקור בפורום CODE613 ב28/04/2014 09:41 (+03:00)

ניסיתי את הצעתי, הנה צילום מסך:

כל הפרוייקט:
WpfMessageLightOff.7z

פורסם במקור בפורום CODE613 ב08/04/2014 17:52 (+03:00)

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

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

פורסם במקור בפורום CODE613 ב08/04/2014 16:08 (+03:00)

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

בפועל אולי עם התקנה יותר יוקרתי, אבל ללא התקנה הרבה יותר פופולרי.
אני אישית מעולם לא בניתי התקנה.

פורסם במקור בפורום CODE613 ב08/04/2014 16:08 (+03:00)

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

פורסם במקור בפורום CODE613 ב01/09/2015 16:13 (+03:00)

רחמים, מיצית אותי.
הצלחה בכל.

פורסם במקור בפורום CODE613 ב08/04/2014 11:58 (+03:00)

שוב, לדעתי המיון מיותר. מתשובתך ניכר שנמאס לך לעיין בנושא...

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

פורסם במקור בפורום CODE613 ב08/04/2014 11:19 (+03:00)

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

לפי מה שנראה לי, Dictionary מהתחלה יעשה את העבודה מהר יותר.

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

פורסם במקור בפורום CODE613 ב07/04/2014 19:24 (+03:00)

@רחמים

כעת סיימתי את הנסיון, תחילה הכנסתי את כל המילים לרשימה אחת ארוכה, אח''כ מיינתי ואח''כ הסרתי כפולים במקום 20 דקות זה הסתיים ב 40 שניות עבור המיון ועוד 7 שניות עבור הסרת איחוד הכפולים !!!

שתי שאלות:
כמה איברים יש?
איך הסרת כפולים?

פורסם במקור בפורום CODE613 ב07/04/2014 16:57 (+03:00)

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

פורסם במקור בפורום CODE613 ב07/04/2014 16:34 (+03:00)

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

פורסם במקור בפורום CODE613 ב07/04/2014 16:08 (+03:00)

להרחבת הידיעות אודות סוגי הקולקשיינס:
http://geekswithblogs.net/BlackRabbitCoder/archive/2011/06/16/c.net-fundamentals-choosing-the-right-collection-class.aspx
והנה עוד מMSDN

בקשר לסוגי המילונים - מפתח-ערך, הנה תמונה מתוך ספר C# in nutshell שנותנת אינדיקציה לשם מה עשוייה כל אחת:

לצפייה טובה לחצו קליק ימני על התמונה > פתח בכרטיסייה חדשה.
המספרים הם אלפיות שניה, לביצוע 50,000 פעולות, במחשב הבדיקה (1.5 Ghz).

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

פורסם במקור בפורום CODE613 ב07/04/2014 15:58 (+03:00)

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

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

Sub mySub(ByVal list As List(Of myType))
    For Each myType As myType In list
        ' בודק אם המפתח כבר קיים
        Dim key As List(Of Integer)
        If dic.TryGetValue(myType.A, key) = False Then
            key = New List(Of Integer)
            dic.Add(myType.A, key)
        End If
        dic(myType.A).Add(myType.B)
    Next
End Sub

(בטעות בקוד לשי הטיפוס הוא int במקום מערך של int, אבל העיקרון זהה).

אם אתה מקבל את כל הנתונים בבת אחת אני גם חושב שעדיף לרכז לבסוף.
תוכל להיעזר בשאילתת לינק לקיבוץ משהו כזה:

Sub mySub(ByVal list As List(Of myType))
    Dim q = From el In list
            Group el By el.A Into grp = Group
            Select New With {.Key = A, .Ints = grp.SelectMany(Function(x) x.B)}
    ...
End Sub

פורסם במקור בפורום CODE613 ב07/04/2014 15:53 (+03:00)

@רחמים

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

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

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