מוסיפים אירוע שינוי לDataTable. משהו כזה:
AddHandler dataSetInstant.TableName.RowChanged, Sub(s, e) DataAdapterInstance.Update(e.Row)
פורסם במקור בפורום CODE613 ב04/03/2014 13:04 (+02:00)
מוסיפים אירוע שינוי לDataTable. משהו כזה:
AddHandler dataSetInstant.TableName.RowChanged, Sub(s, e) DataAdapterInstance.Update(e.Row)
פורסם במקור בפורום CODE613 ב04/03/2014 13:04 (+02:00)
כפי שClickOne אמר, ואין הבדל בין מקומי למרוחק.
נגיד זה הקונקשיין:
Server=ComuterName\SQLEXPRESS;Database=myDataBase;User Id=myUsername;Password=myPassword;
אז הComuterName צריך להיות השם של המחשב, בין אם הוא קרוב או רחוק. אפשר במקום שם הIP (זה גם רצוי, כי לפעמים הDNS נכשל).
עריכה:
בקשר למושגי רשת אינני מבין גדול, אך בשתי מילים: ברשת מקומית, וזה אומר שלכולם יש קבוצת עבודה אחת/תחום אחד, לכל מחשב חייב להיות א. שם ייחודי, ב. IP ייחודי.
בנוגע לרשת לא מקומית: הIP נקבע ע"י הספקית, ואפשר להשתמש בו או בURך מדומיין שרשום לIP זה.
במידה ובין המחשב לרשת אין מודם אלא ראוטר, זה נחשב כאילו שיש רשת של מחשבים פנימית עם IP פנימי לכל אחד, וIP ראשי שזה הראוטר - זה גם הכתובת החיצונית של כל המחשבים ברשת הפנימית. במקרה של גישה ממחשב חיצוני לרשת הפנימית יש להשתמש בIP החיצוני ולהגדיר בראוטר חלאפשר גישה ישירה למחשב המסויים בו יש את המסד.
פורסם במקור בפורום CODE613 ב03/03/2014 13:48 (+02:00)
נסיוני: http://code.613m.org/searchbygoogle.php
פורסם במקור בפורום CODE613 ב19/03/2014 17:17 (+02:00)
@דוד ל.ט.
שבלי עזרה ממפתח המחלקה אין אפשרות כזו
במקרה שלי מפתח המחלקה הוא אני
אני מדבר על ארוע קליק שמגיע מוכן עם הלחצן גם אתה מתכוון לזה או לארוע שאני בעצמי יוצר?
הוא שייך רק בלחצנים של System.Windows.Forms.Button ולא בלחצנים של Microsoft.Office.Tools.Ribbon.RibbonButton
ממש נחמד ככה לשוחח..
אם אתה רוצה עזרה, תפרט, ותקרא היטב מה שכותבים לך.
אני הבנתי כעת מה אתה רוצה, ואני לא יודע איך עשים זאת אך אכן בטוח שזה אפשרי. מסתבר מאו שיש מקום בו רשומים הלחצנים המוגדרים להצגה והפקודות שהם מפעילים. אבל אתה חכם, לא שאלת אפי' אם יש כזה מקום, אלא האם אפשר להפעיל פונקציות שרשומות לאירוע הכפתור*. כשתתבונן בשאלתך תבין עד כמה היא בנויה על הנחות**, עדיף שתגיד מה אתה צריך בצורה הכי ישירה (לא בהודעה שלישית) ולא לשאול על דרך תיאורטית שאולי תפתור לך את הבעיה.
פורסם במקור בפורום CODE613 ב09/03/2014 11:49 (+02:00)
לא בטוח שלגמרי הבנתי.
הרי ברור שאתה שומר את כל המידע להפעלה הבאה של האפליקציה, וממילא אתה מחזיק את הרשימה במקום אחד מאשר באירוע.
עכ"פ, בתור מפתח המחלקה אתה יכול לגשת לרשימת הנרשמים לאירוע ככה
ClickEvent.GetInvocationList()
כאשר הClick זה שם האירוע והתוספת Event היא לפנות לשדה דלגייט נסתר שהקומפיילר יוצר מאחורי הקלעים.
ואגב, בגלל ל"מאחורי הקלעים" הזה יש עלות מסויימת בזיכרון, שאיננה בC#. בשביל למנוע את זה במקרה נצרך (ריבוי משמעותי של אירועים שבד"כ לא נרשמים אליהם) יש תחביר מיוחד בשם Custom Event הנה פרטים עליו: http://msdn.microsoft.com/en-us/library/yt1k2w4e.aspx
פורסם במקור בפורום CODE613 ב06/03/2014 21:49 (+02:00)
אירוע זה Delegate עם כמה הגבלות קטנות (שכאן בדיוק עומדות לרעתך...).
איך זה עובד כתבתי פעם במדריך.
ההגבלה שתוקעת אותך כאן, זה העובדה שאירוע מוגן מפני גישה למתודות שנרשמו אליו, לעניין הסרתם/הפעלתם/קבלת שמותיהם.
בעוד שבDelegate רגיל כתיבת שמו מפעילה את כל הפונקציות שנרשמו אליו, באירוע יש לך גישה לפונקציות רק אם אתה במחלקה שהכריזה על האירוע (ע"י שמו ובVB ע"י RaiseEvent). כמו"כ אתה יכול לעבור על הרשימה של המתודות וכו'. אבל מחוץ למחלקה שמכריזה על האירוע, אתה יכול להוסיף מתודות, ולהסיר את אותם מתודות שהוספת, ולא יותר.
תכל'ס לענינך, אם המקרה הוא פקד של WPF ישנה אפשרות כזאת:
ButtonInstance.RaiseEvent(New RoutedEventArgs(Primitives.ButtonBase.ClickEvent))
אז למה כל ההקדמה? כדי להדגיש שבלי עזרה ממפתח המחלקה אין אפשרות כזו (בלי להיכנס לreflection, זה כבר אני לא יודע אבל כמעט בטוח שגם שם א"א).
פורסם במקור בפורום CODE613 ב06/03/2014 18:56 (+02:00)
מן הסתם זה ילך ל TRASH ולא ממש יימחק והרווחת שזה לא יופיע יותר
שין לב שהוא ביקש שיהיה כ"נקרא". לא אשפה. אולי זה עוזר לו אבל לא מה שהוא שאל.
וחוץ מזה מסוכן להציע את זה בעיניים עצומות זה הרי תלוי במדיניות שרת המייל.
פורסם במקור בפורום CODE613 ב24/02/2015 20:04 (+02:00)
soft עזוב את ג'מייל, בPOP3 יש אפשרות לבקש מהשרת לסמן כנקרא?
פורסם במקור בפורום CODE613 ב24/02/2015 19:06 (+02:00)
הפרוטוקול POP3 לא מאפשר לשמור מידע כל שהוא בצד שרת, וממילא הדרך היחידה שלו לדלג על מיילים שהוא קרא זה ע"י שמירת הID שלהם בצד הלקוח ודילוג עליהם בכל קריאה.
מחיפוש באינטרנט:
http://stackoverflow.com/a/352347/1271037
It's the responsibility of the POP3 client to check for this.
ובעברית: עניין זה הוא באחריותו של הלקוח - התוכנה שמושכת את המיילים.
פורסם במקור בפורום CODE613 ב24/02/2015 16:31 (+02:00)
יש תגית שאומרת לו שהשיחה נקראה לפי הID שלה.
אני חושב שזה uidl.
אבל ארכיטקט, אתה משתמש בספריה כלשהיא, או מימשת לבד את הפרוטוקול? כי ספריות אמורות להכיל מתודה לזה.
אגב, אם אתה רק קורא, וזה GMAIL, בדוק את זה http://stackoverflow.com/q/989986/1271037. סמן בצד שלך מה כבר קראת וזהו.
פורסם במקור בפורום CODE613 ב24/02/2015 15:25 (+02:00)
@יויו שר
אני צריכה להוסיף תצוגה של טבלה נוספת לדוח crysalReports . יש לי את הקוד בvisual studio . אין לי גישה ליישום crysalReports יש אפשרות להוסיף רק באמצעות visual studio
אנא פתחו אשכול חדש עם פירוט מלא של הבעיה.
פורסם במקור בפורום CODE613 ב15/11/2017 09:49 (+02:00)
א. לא הסברת מה לא היה מובן בנושא החיסכון בזיכרון.
ב. כמה רמות של פירוש זה לא בעץ הויזואלי וממילא מיושבת שאלתך, נכון?
כמה רמות זה אב תצוגה כל שהוא (גם 100 וגם 1), סטייל, ערך ברירת מחדל וכו'.
תוכל לראות את הרשימה פה.
וכעת שנכנסתי שם ראיתי שיש 11.
פורסם במקור בפורום CODE613 ב18/02/2014 16:55 (+02:00)
@דוד ל.ט.
במידה ויש רוחב מפורש, אז נוצר מקום בזיכרון מפורש. החיסכון הענק הוא על הלא מפורש.אם הרוחב לא מפורש צריך להריץ פונקציות כדי לשכלל אותו על פי פקד האב שמכיל אותו וכדומה ושוב הפונקציות זוללות זיכרון כי הן באלפים עבור כל פקד וכל מאפיין.
@דוד ל.ט.
למעשה תמיד מפורש רק השאלה באיזה רמה, ישנם כמעט עשרה רמות כמדומני, התחתון שבהם הוא באלמנט עצמו, ואז אכן אין שום חיסכון בזיכרון.
לאלו רמות אתה מתכוון, ואיך זה חוסך בזיכרון?
באשר לשאלת הפונקציות, אז דבר ראשון פוקנציות זה לא זיכרון, ופונקציה שלא מופעלת נחשבת כלא תופסת משאבים כלל.
דבר שני, מבחינת עיבוד אתה צודק שיש פה עלייה לעומת מאפיין רגיל, במיוחד שזה עובד עם תנאים אבל מושגי עיבוד אלו לא ראויים בכלל ליחס.
מה כוונת המשפט "איך זה חוסך בזיכרון"? אני אולי ינקד את ההודעות הקודמות? או שלא הסברתי מספיק אבל לא הצבעת על נקודה כזו.
באשר לרמות, היה נראה שאתה מכיר לפחות אחת ("פקד האב וכדומה"), בא נאמר שהשאלה של הזיכרון הובנה, וזה נושא חדש להזדמנות אחרת, בסדר
?
פורסם במקור בפורום CODE613 ב18/02/2014 16:18 (+02:00)
@דוד ל.ט.
בWPF יש מאפיינים מיוחדים (DP) שחוסכים זיכרון כי למאה אובייקטים יש משתנה אחד (נגיד Width - רוחב אלמנט), יש שיתוף משאבים בין כלל האובייקטים בתוכנית.ילמדנו רבינו:
איך זה קשור לDP? גם מאפיינים רגילים יכולים כולם להיות קשורים לאותו משתנה?
וגם עצם הדבר לא מובן לי הרי לכל פקד יש רוחב שונה?
קודם שאלה שנייה: במידה ויש רוחב מפורש, אז נוצר מקום בזיכרון מפורש. החיסכון הענק הוא על הלא מפורש. למעשה תמיד מפורש רק השאלה באיזה רמה, ישנם כמעט עשרה רמות כמדומני, התחתון שבהם הוא באלמנט עצמו, ואז אכן אין שום חיסכון בזיכרון.
כעת לשאלה ראשונה: איך זה קשור לDP, גם במאפיינים רגילים אפשר. התשובה היא שלילית. במאפיינים רגילים, אם אתה רוצה שכל המופעים יחלקו זיכרון אחד, אז אתה מצהיר עליהם כסטטיים, ואז גם אם בא לך שאחד יהיה שונה, אז אתה צריך לכתוב קוד מיוחד לזה ולדאוג לנהל ת'עסק. זה הDP חוסכים.
חשוב להבין שבשביל עשרות אובייקטים זה לא משמעותי (תלוי בסוג המאפיין), אבל בחלון XAML פשוט ייתכנו אלפי אלמנטים (לכל אלמנט יש מאות מאפיינים).
פורסם במקור בפורום CODE613 ב18/02/2014 16:00 (+02:00)
ארכיטקט העניינים ממש לא מסובכים כמו שנראה לך...
מאפיין זה סה"כ פונקציה מחזירה ופונקציה מגדירה. כמו כל פונקציה שאנו בונים בתוכנית.
בWPF יש מאפיינים מיוחדים (DP) שחוסכים זיכרון כי למאה אובייקטים יש משתנה אחד (נגיד Width - רוחב אלמנט), יש שיתוף משאבים בין כלל האובייקטים בתוכנית.
פורסם במקור בפורום CODE613 ב18/02/2014 14:44 (+02:00)
כשניגשים למאפיין, במידה ולא אנו כתבנו אותו, יש לקחת בחשבון שזה אפשרי שהוא מבצע פעולה מורכבת מאשר לגשת ולהחזיר ערך משתנה. לדוגמה מאפיין נפח של קוביה יחזיר את הכפל של מימדיו ולא יאחסן זאת בזיכרון, ובמידה ואנו פונים הרבה פעמים (או בצורת כלל: יותר מפעם אחת) למאפיין זה של אותו אובייקט, יותר טוב לשמור את ערכו במשתנה ולגשת אליו שוב ושוב מאשר למאפיין.
אבל מאידך, בכתיבת מאפיינים הכלל המנחה הוא שכשנדרשת פעולה מורכבת להחזרת הערך, לא עושים מאפיין כי אם פונקציה (בתור חיווי למתכנת שזה פעולה יקרה יחסית, ועדיף שהוא ידאג לשמור את הערך במידה והוא צריך אותו שוב).
פורסם במקור בפורום CODE613 ב18/02/2014 10:36 (+02:00)
לא כ"כ הבנתי מה רחמים פתר לך.
האופרטור ?? עובד רק על טיפוסים Nullable שזה כאלו עם סימן שאלה בסוף שם הטיפוס. אני מבין שהDate שלך הוא לא Nullable.
אז מה הפתרון שע"י הסתדרת?
ורחמים, למה הבאת את הקוד עם מתודה זו: static void Main(string[] args)?
אם זה לצרכי בדיקה, אז אתה יכול להשמיט זאת מהקוד בפורום (לא לחיסכון אלא להדגשת נקודת הפתרון.
פורסם במקור בפורום CODE613 ב18/02/2014 10:08 (+02:00)
לדעתי במקרים רגילים מה שאמרת עם העלאה ושמירה במספור ואח"כ שמירה ללקוח עם שם מקור זה דרך נכונה.
בקשר לעריכה בו זמנית, אז באמת צריך לעשות נעילה בזמן ההורדה לעריכה עד סיום העלאה.
זה נכון שלSQL SERVER יש מעלה בניהול אוטומטי של מנגנון הנעילות.
פורסם במקור בפורום CODE613 ב04/03/2014 09:22 (+02:00)
אני הייתי עושה תיקייה עם הרשאות רק למשתמש של הSQL SERVER, ומוחקים וכותבים רק דרכו.
פורסם במקור בפורום CODE613 ב25/02/2014 16:10 (+02:00)
אין ספק שקבצים בDB זה גרוע.
לפעמים צריך לאחסן את חתימת הקובץ (CRC או כל זיהוי אחר) ואז זה בסדר גמור.
שדה בינארי באורך משתנה, ומידע מיותר, זה לדעתי ממש משחית את יעילות הDB.
פורסם במקור בפורום CODE613 ב16/02/2014 14:22 (+02:00)