פורום שבו שותפים אנשים מקצועיים כל כך, התחיל בצמיחה מרשימה מאוד, ולאחרונה הפעילות בו הולכת ודועכת, אל תיתנו לזה לקרות!!!
בפורומים הגדולים 99% מהחברים הם ברמה מקצועית נמוכה מאוד, חבל על פורום כל כך יוקרתי ואיכותי, זאת הזדמנות פז עבור הציבור החרדי המקצועי האמיתי, לשתף מידע ברמה גבוהה ומקצועית, חבל חבל חבל על ההזדמנות.......
פורסם במקור בפורום CODE613 ב08/11/2013 13:16 (+02:00)
קודם כל אני שמח לראות שגילית את עולם הבידניג שבשביל זה ירד WPF לעולם בעצם... ואל תגיד שזה לא בזכותי 
לגבי ערפול אני לא יודע איך המנגנון עובד, ייתכן שאם זה כלי עירפול של מייקרוסופט הם לקחו את זה בחשבון מן הסתם, אתה יכול לנסות.
באופן כללי אני לא יודע אם יש מה להרויח בערפול קוד כאשר אתה עושה לאנשים מסויימים תוכנה, החשש להעתקות הוא נדיר, כשלא מדובר בתוכנה בינלאומית, או תוכנה פשוטה מאוד מאוד לתפעול. וגם אם תימצי לומר שיעתיקו מי יתחזק להם וכולי. לא יודע. אני סבור שמתכנת מחזיק הרבה כוח בידיים מבחינת הארגון, אף ארגון לא רוצה לקחת סיכון שהמתכנת לא מספיק מכיר את התוכנה, וגם מתכנת נורמלי לא ישתף פעולה עם פשע של העתקה, אז מה בדיוק החשש....
לגבי בינדינג בסטייל או טמפלט אני זוכר שיש דבר כזה, צריך לדעת איך להגדיר את הרפרנסים והריסורסים בתחילת הקובץ ואז יש התייחסות למחלקה שאתה משתייך אליה.
פורסם במקור בפורום CODE613 ב07/11/2013 23:18 (+02:00)
אפשרי גם אפשרי
אתה צריך ללמוד את העיקרון של דטה בינדינג, בגדול מה שאמור להיות זה ככה:
יש מאפיין שמשתנה
בשעה שהוא משתנה הוא מציף אירוע שמדווח לכל המחלקות שהמאפיין הזה השתנה (וזה על ידי אירוע בשם PropertyChanged הממומש ב INotifyPropertyChange עיין כאןהסבר)
כל מה שקשור איכשהו למשתנה הזה, מקבל את הדיווח
ממילא גם התצוגה שקשורה בדטה בינדינג לאותו מאפיין מעדכנת את עצמה ומבקשת את הערך מיידית מהמאפיין ומרעננת את התצוגה.
עכשיו לענינך, הדטה גריד שלך סביר להניח שעומד מאחוריו אובייקט (דומני שזה הכרחי) האובייקט הזה הוא אוסף בדרך כלל אחד ממיני האוספים הרבים של דוט נט.
כעת האוסף הזה צריך להיות מאפיין, ולא שדה (בכל מקרה אין אפשרות לכריכת נתונים אלא על ידי מאפיין).
במקביל אתה עושה מאפיין (get בלבד, אין טעם ל set) שתפקידו יהיה להחזיר את הסכום מהאוסף הנ"ל.
הפקד שמכיל את הסכום יהיה כרוך למאפיין שנותן לו את המידע אודות הסכום.
עכשיו, אתה צריך אירוע שברגע שאותו אוסף משתנה (כלומר מתווסף לו איבר או משתנה ערך של אחד האיברים) כלומר ב set של אותו מאפיין שבעצם מכיל את המידע של הדטה גריד שלך, לעשות PropertyChanged שיכריז על [u:1l0zqa23]המאפיין שמחזיר את הסכום[/u:1l0zqa23], שהוא השתנה, כך, שהפקד התצוגתי יבצע מיידית ריענון וישאל מחדש את המאפיין של הסכום מה המצב??? ואז אותו מאפיין יפעיל את ה get שלו ויודיע לו את המצב לאשורו.
כעת אינני זוכר טוב אבל ייתכן שתיתקל בקושי לעקוב אחרי האובייקט שמכיל את המערך, כלומר ייתכן שאין ריצה של set כאשר מוסיפים איבר למערך, אשר על כן מייקרוסופט עשו משהו שנקרא ObservableCollection שאמור לדעת גם מתי מוסיפים לו איבר, ויש שלא הסתפקו גם בזה ופיתחו גם TrulyObservableCollection שאל את רבי נחמן מגוגל ותמצא נחת. ואם לאו אני מניח שדוד ל.ט. יידע לעזור לך.
פורסם במקור בפורום CODE613 ב03/11/2013 19:38 (+02:00)
לדעתי זאת טעות להשתמש באירוע, אחת הבשורות של WPF הוא הנתונים המקושרים באמצעות Data Binding למד אותו היטיב וחייך יהפכו לטובים יותר, בכל כה"ג של הצגת מידע על המסך אין להשתמש אלא בדטה בינדינג כמו"כ בעוד הרבה מאוד מוניפולציות שאנשים היו רגילים לעדכן אותם בגסות, כדאי מאוד לאמץ את הרעיון של דטה בינדיג שאגב תפס מאוד בעולם התיכנות זאת המצאה של מייקרוסופט, שהרבה בקוד הפתוח מנסים לחקות אותה אחריהם, ואפילו גוגל באנגולר שלהם.
אגב אם תוכל להשלים לי את התשובה לשאלה הזאת
פורסם במקור בפורום CODE613 ב02/11/2013 19:09 (+02:00)
הפרוייקט כרגע לצערי ב vba אקסס הספריות יעבדו אותו דבר??
תודה
פורסם במקור בפורום CODE613 ב31/10/2013 13:01 (+02:00)
שלום
לקוח אחד מבקש ממני לסנכרן משימות ואירועים עם אאוטלוק, הם אוהבים את התצוגה של אאוטלוק, לוח שנה וכדומה, שזה מן הסתם דברים שלוקחים יותר מדאי זמן לבנות לבד.
יש איזה API מסודר איך לחדור את אאוטלוק בקלות, והאם יש דרך להתמודד עם העובדה שלכל ארגון יש מערכות שונות, ושדות שלא קיימים באאוטלוק באופן טבעי.
אני אישית משתמש באאוטלוק אך ורק כדי לשלוח ולקבל אימיילים, ואינני מכיר כלל את הקרביים של הכלי הזה. כל קישור/עזרה/הארה יתקבל בברכה.
פורסם במקור בפורום CODE613 ב30/10/2013 21:18 (+02:00)
א. הינני להודיעך כי wpf כולו בנוי כמו כרטסת באקסס, הרעיון של פקד שמכיל פקד זה האלף בית של WPF כך שלא משנה במה תשתמש תוכל לקרוא לזה "כרטסת" אפשר להכניס גם וידאו בתוך גריד למשל.
ב. מה זה אם לא כרטסת קוראים לזה באנגלית tabcontrol
ג. שמעתי פעם הרצאה ממישהו בנידון חברת UI שמתמחה ב WPF יותר ממייקרוסופט עצמם, הוא אומר שבעצם אפשר לממש המון רעיונות עם הפקד כרטיסיה שיש שם, הוא הראה כמה דוגמאות, אני די חלוד בנושא ולא זוכר. בכל מקרה WPF נועדה בעיקר כדי שתוכל ליצור פקדים, ולא כדי שתחפש פקדים מוכנים........ אז אם כבר עברת מאקסס, כדאי לחשוב ביצירתיות איך לנצל את היכולות המדהימות של WPF כדי ליצור חוויית משתמש הרבה יותר עשירה מאשר שימוש בנאלי בפקדים קיימים.....
פורסם במקור בפורום CODE613 ב29/10/2013 22:04 (+02:00)
זה קורה כשמצהירים על אובייקט רקורדסט או דאטאבייס? או סתם?
סתם
@ClickOne
כי אני נתקלתי בזה בעבר כשיצרתי מתוך התיקייה וכו' - שם כברירת מחדל שם הפרוייקט בVBA הוא Database וזה מייצר התנגשות מסויימת - בעיקר ברקורדסט,עד שמחליפים את שם הפרוייקט בVBA.
זה משהו אחר לא קשור.
כנראה שהנושא אכן קשור איכשהו לקידוד, כי הבעיות נוצרות בשמות של פונקציות בעברית בלבד.
פורסם במקור בפורום CODE613 ב27/07/2014 20:01 (+03:00)
היום הבנתי שזה קורה כשיוצרים קובץ אקסס מתוך חלון windows במקום ליצור את זה מתוך אקסס.
הפתרון הוא ליצור קובץ חדש מתוך אקסס עצמו, ולייבא את כל האובייקטים למסד החדש ואז זה נפתר.
פורסם במקור בפורום CODE613 ב27/07/2014 16:00 (+03:00)
לדעתי יש כאן נידון של "דת ומדינה" וכבר דיברתי על זה עם דוד ל.ט. כמה פעמים, זה קצת מזכיר גם את הויכוח בין הלינוקסאים, לבין משתמשי מייקרוסופט, אקסס זה המיצוי של העולם המייקרוסופטי, איך שהגדיר את זה פעם חבר שלי, מייקרוסופט זה כמו בית אבות סיעודי, אתה יושב על כיסא גלגלים, וכל מה שהגוף צריך מספקים לו עד למקום. לינוקס ועולם הקוד הפתוח, זה העולם החופשי, שבו אתה יכול לרוץ לכל מקום שאתה רוצה גם עד ל VHDL אם יש צורך, בלי להצטרך לשום שירות סיעודי (אם כי קיימים בלי סוף למי שמעוניין, אבל זה לא "משעבד" אותך, וזה ההבדל הגדול)
ואז עונים משתמשי מייקרוסופט, אתה לא תוכל להיות תחרותי אם תנסה לכתוב הכל מאפס, אנחנו חיים במשק מווסת מחירים, הזמן שאנחנו חיים הוא משאב מוגבל לעת עתה, וצריך לדעת שפרוייקט שלקוח שנתיים בקוד פתוח, יכול לקחת חודשיים בדוט נט וכדומה. אז זה אותו ויכוח מבחינת התוכן. אם הלקוח צריך משהו שאקסס מספיק לו, אתה יכול לכתוב תוכנה ב 3 שעות, מה שייקח לך בדוט נט וסביבותיה, בערך חודש. איי מה תגיד, מה יקרה אם הלקוח ירצה משהו שאין באקסס, התירוץ הוא מציעים לו פתרון עוקף, או שמסבירים לו שאם היינו הולכים בדרך אחרת, זה היה עולה לו פי שמונה, ברוב המקרים התירוץ הזה עובד לא רע בכלל. מניסיון.
אז אם כבר, אפשר לפתוח את הויכוח העתיק והבלתי נגמר, בין עולם הקוד הפתוח, התקן הבינלאומי, האינטרנט הנייטרלי על כל בעיות הכאוס לכאורה שיש שם. לבין העולם החשוך של מייקרוסופט, שבו יש אוליגרכיה גמורה שלטון ללא מצרים שמכריח אותך לעבוד איתם בכל תחום וכן הלאה. אז אולי כבר נדון על דת ומדינה, או על צורות שלטון.
אני מבקש סליחה אם נסחפתי, אבל לדעתי זהו הדיון האמיתי כאן.
פורסם במקור בפורום CODE613 ב12/10/2013 20:09 (+03:00)
באמת שאלה טובה............
סתם בשביל ההתעללות, כשסובלים ממייקרוסופט, מתחרטים על הרגע שנכנסנו למלכודת הדבש שלהם. כשמתחילים איתם זה נראה שהכל הולך קל, אבל כשנתקלים בבאגים שלהם, אתה מזיע רטרו אקטיבית על כל מה שנהנית, כך שה"קלות" שמייקורוספט נותנת לך בתחילת הדרך, זה רק בהלוואה, עם ריבית גבוהה מאוד..........
במחילה מכל חסידי מייקרוסופט, שגם אני נכללתי בהם בעבר.......
פורסם במקור בפורום CODE613 ב09/10/2013 02:05 (+03:00)
תודה רבה!!
אז אני מבין שמבין החינמיים הפורום שאני גולש בו הוא הכי פחות בעייתי..
בכל מקרה השיקול הכלכלי כאן הוא זניח, מפני שלהחזיק מזכירה או צוות תמיכה, זה סיפור הרבה יותר יקר מאלף שקל....... כך שכל ייעול אפילו של אחוז אחד בפורום, מדבר על חיסכון ישיר של כסף או זמן עבודה יקר ערך.
בכל אופן יישר כוח. אבדוק את האופציות בתשלום אם זה המצב בשוק.
פורסם במקור בפורום CODE613 ב30/09/2013 23:57 (+03:00)
שלום לכולם ולמנהל הפורום בפרט, רציתי את עצתכם לגבי הקמת פורום פרטי לחברה שלנו, פורום שמטרתו היא עזרה ותמיכה בתוכנה ספציפית, מהם האופציות הנפוצות, רמות גמישות והתאמה אישית, עקומת למידה ותמיכה קהילתית רחבה.
כאדם שאיננו בעל רקע עשיר מידי בווב, הייתי רוצה ללמוד מניסיונם של אחרים, בגדול הצרכים שלי הם כאלו.
ישנה הדרכה בסיסית לתוכנה, שהיא מועברת בדרך כלל בסרטוני וידאו קצרים מאוד, לכל נושא יש נניח 10-20 סרטונים של 2-4 דקות, בכל סירטון המשתמש אמור לעלות דרגה בידע שלו. כעת אני רוצה גם שתהיה אפשרות של דיון שאלות ותשובות (בערך בסגנון של סטאק אוברפלוו) אולם שכל הדיונים השאלות, התשובות, יהיו מאושכלים בצורה שלא תגרום עם הזמן להצטברות ערימות שחת. כלומר תהיה אופציה למשל שאם יש שאלה שהתשובה עליה כבר קיימת, פשוט להציב את התשובה הקיימת גם במקום של השאלה, וכן אישכול של שאלות לפי תתי נושאים וכולי כמו עץ. בנוסף כמובן גם מנוע חיפוש ידידותי, ושההדרכה והשו"ת יהיו במקום אחד, לא לפצל ל 2 מקומות. החלום שלי הוא שתחת כל סרטון יהיה גם שאלות ותשובות מהמשתמשים. או ביני לבין המשתמשים.
בתקוה שהתיאבון שלי לא גדול מידי על מה שיש בשוק, ושאתם מבינים למה אני מצפה.
פורסם במקור בפורום CODE613 ב28/09/2013 21:45 (+03:00)
בחירת שמות "נכונים" לאובייקטים היא אבן יסוד לשליטה על קוד.
הקישורים שיש כאן שלח לי רבי קשורים לרעיון הזה.
http://web.macam.ac.il/~tamil/psychology/4language.htm
http://www.calcalist.co.il/local/articles/0,7340,L-3415756,00.html
http://www.ovzap.net/whorf/index3b.html
אם יש לנו שיטתיות עקבית וקשוחה בקריאת שמות, זה נותן לנו יתרונות רבים, סביר להניח שלא נחזור בטעות לכתוב פונקציה שכבר כתבנו בעבר, כי כאשר נבקש לכתוב אותה, נבחר לה שם שכבר בחרנו, ונכתוב אותה בקלאס הנכון, ואז מייד יוודע לנו שבעצם כבר יש בידינו פונקציה שעושה את העבודה (לי אישית זה קרה הרבה פעמים). דבר שני, נדע למצוא מייד את הפונקציה גם כאשר אנו זוכרים שכתבנו אי פעם פונקציה שעושה את העבודה הזאת, אבל לך תמצא אותה בתוך הערימה של הפונקציות. דבר שלישי, זה עצמו מרגיל אותנו לכתוב קוד מסודר, ברור וקריא, כי בשיעורים הבאים נלמד על פיזור סמכויות בין פונקציות וזה נגזר ממודעות ברורה בנושא קריאת השמות, כך שהקריאות של הקוד בעצם מאפשרת לנו לחסוך המון עבודה מיותרת, וככל שנתקדם יותר, כך עקומת הזמן שבה לוקח לנו ליישם בקשה של לקוח, תלך ותרד עם הזמן.
אעיר כי הנושא הזה של קריאת שמות לדברים, הוא קודש קודשים, ושייך לגמרי לבית המדרש וליסודות הדת.
הבה ונתחיל מהעקרונות.
לפני שניגש למתודולוגיה שתנחה אותנו ב"איך לקרוא שם" ו"מה השם אמור לייצג", נבהיר את העקרונות בגדול.
שמות של אובייקטים, לא משנה אילו אובייקטים, טבלאות, שדות, מחלקות, פונקציות, מאפיינים. צריכים לעמוד ב 3 קריטריונים:
1. שיטתיות ועקביות
יש לקרוא בשמות באופן שיטתי ולא לפי "מצב הרוח"
להקפיד מאוד על לשון יחיד ורבים לפי ההקשר (כל אוסף או מערך למשל תמיד ייקרא בלשון רבים!!!)
להקפיד מאוד על תחביר נקי, אותיות חיבור, שמות נושאים ונשואים לפי סדר קבוע, ועוד דברים כפי שנראה בהמשך.
להקפיד על עקביות בנושא בחירת ייצוג השם, כפי שנדבר על כך להלן, ישנם כמה דרכים לשמות בעלי משמעות, איך לבחור שם לאובייקט.
2. ענייניות ומשמעותיות
על השם להיות ענייני ובעל משמעות ולא מקושקש!
וכאן אטיל פצצה קטנה ויש יאמרו שאני קיצוני:
אם אין לכם שם לפונקציה תעצרו את העבודה, עד שתמצאו לה שם, כי אם אין לכם שם, יש חשש גדול להניח שהפונקציה שלכם "מלוכלכת". והדברים אמורים גם אם הלקוח שלכם מתפתל מכאבים ודוחק בכם לסיים!! עוד נדבר על היחסים עם הלקוח בנושא הזה בשיעורים הבאים.
אסביר מדוע: אדם הראשון מיד כשנברא קרא בשמות לכל הסביבה שלו, גם לעצמו הוא קרא בשם. דבר שהוא נטול שם, הוא חסר עצמיות מוגדרת, וככזה הוא חסר יכולת להתפס בהכרתנו. וכאשר אתה לא מוצא שם למשהו (על כך נדבר להלן, את מה השם אמור לייצג), אז עבורך זה לא משהו מוגדר ומובחן, וזו בעצם בעיה יסודית הכרתית, ולא בעיה טכנית!!! , וככל שהשם מובחן יותר, כך היחס שלך לעצם, הוא עמוק יותר. אז בארכיטקטורה אנחנו זקוקים לשמות בעלי תוכן מובחן, לא בשביל "להסתדר" אלא גם בשביל לוודא שהקוד שלנו נכתב בצורה נכונה.
מורי ורבי גם לימד אותי שהדבר החשוב ביותר שאפשר להקנות לילד, זאת שפה תקינה!!! את ההסבר לכך סיפקנו כרגע.
3. בהירות
על השם להיות נהיר לקורא ולהכיל מבחינתו את כל מה שצריך לו לדעת בעת הקריאה הראשונית!!! לא להשתמש בקיצורים וראשי תיבות (אלא אם כן בדברים מקובלים שכבר הפכו להיות שפה ברורה, כגון קידומת או סיומת str שכולם יודעים שזה string. אבל מי שכותב פונקציה וקורא לה GetCustIDByProName הוא מבחינתי מאבד עצמו לדעת, למרות שמשמעות הפונקציה היא, לקבל את מזהה הלקוח לפי שם של פרודוקט, יש כאן חיסכון משונה באותיות, שזה תחביב מגונה של הרבה מתכנתים, "לדבר בלשון קצרה". אז בואו ונעדיף את הבהירות מאשר את הקיצור בעניינים אלו.
כעת ניגש לשאלת השאלות, "מה השם של הפונקציה אמור לייצג", האם את התוצאה שהיא מחזירה? את העבודה שהיא עושה? ומה יהיה כשהיא בעיקר עושה עבודה, והתוצאה היא רק "מידע" על העבודה שנעשתה. וכן הלאה וכן הלאה. הנושא הזה הוא כל כך טעון, עד שהוא בכלל לא מתאים לפורום הזה. הייתי כותב ספר שלם רק על הנושא הזה, מבחינת שפה. יש לא מעט מחקרים בתחום, אבל בהקשר של שפת הדיבור. וכולם אין בהם משום "בנין" שפה אלא "ביקורתה וסתירתה". ולכן הנטייה היא להשתמש יותר באינטואיציות. אבל לפי דעתי יש אפשרות לגבש מדיניות מסויימת, גם אם לא עלתה בידינו לחקור את הנושא התורני הזה לעומקו ולרוחבו. לפחות נחזיק בידינו את היתרון שאנחנו עובדים עם מדיניות כלשהי, ולא בפיזור וחוסר סדר. אז מה שנכתוב כרגע איננו מתיימרים להקיף את הנושא, אלא לתת כלים להגיע לקירוב כלשהו עד כמה שאפשר לכללים ברורים.
יש קצת הבדל בהתייחסות לפונקציה בין השפות, למשל ב JS פונקציה היא עצמה אובייקט, ולא משנה מה היא עושה, בדוט נט, יש הבדל בין קלאס, מאפיין ושדה, לבין פונקציה, שהפונקציה נעלמת מייד אחרי שמסיימת את העבודה, ומותירה אחריה רק את הערך שהיא מחזירה, אך אין הדרך לקרוא לה "אובייקט" וכן שגרה לא כל שכן שאיננה אובייקט.
הבה נתחיל מאובייקטים, שם יותר קל לתאר את השיטה. אובייקט, בשפה מונחית עצמים, אמור להיות נקרא בשם כפי שאנו רגילים לקרוא לעצם.
שמו של עצם יכול לייצג אותו בכמה דרכים הנה דוגמאות נפוצות:
שם ראשוני: כגון "שור" "חמור" "ברזל" וכדומה. אי אפשר להסביר למה קוראים לברזל ברזל. (וגם אם אפשר זה לא משנה כי לעולם רובנו משתמשים בשמות אלו כראשוניים ואנחנו מדברים עכשיו מבחינת הכרה רגילה איך הדברים מתנהלים)
שימושיות מובהקת: כגון "מכסה" על שם שמכסים בו, "מראה" על שם שרואים בה, "מרכב" על שם שרוכבים עליו, וכן "מנעול" "מפתח" "עמוד" "מזבח" "מחתה" וכדומה. כל אלו נקראים על שם הפעולות המובהקות שנעשות בהם.
סימליות: היינו שמות המכילים סמל כלשהו, אך אינם מצביעים על שימושו המובהק של הדבר. כגון "מעקה" על שם שמעיקים עליו (מפי רבי) "חולצה" על שם שחולצים אותה (מפי רבי) "חבית" על שם שהנוזל חבוי בה, או "כף" על שם שנראית כמו כף יד אדם (כף היד היא מן הסתם שם ראשוני), ובשפה מודרנית יש כיוצא בזה ממש על ידי, "עכבר" "מסך" "אוזניות" וכדומה.
שמות של פעולות, אף הן יכולות לייצג מגוון היבטים:
הפעולה עצמה (בדרך כלל כשם ראשוני): כגון שלוף, הגדר וכדומה.
וכאן יש הבדל בין פונקציה לשגרה לבין אובייקט, ככלל, כל דבר שמחזיק ערך בתוכו, כגון משתנה, מאפיין או מחלקה (במידה ותפקידה להחזיק ערכים) וכדומה, שמו אמור לייצג את עצם הערך שהוא מחזיק. ואילו פונקציה שמחזירה ערך, שמה אמור לייצג "פעולת ההחזרה". אם תבדקו במייקרוסופט הם די מקפידים על זה, על ידי קידומת "Get" לפני פונקציות שמחזירות משהו. ואילו בשמות של מאפיינים אין את הקידומת get.
הסיבה לכך היא פשוטה, פונקציה היא "כוח עבודה" היא איננה אובייקט, ואילו מאפיין או משתנה, הוא אובייקט. אז כשיש לנו מאפיין או משתנה שמכיל רשימת אנשי קשר נקרא לזה "Contacts" ואילו כשיש לנו פונקציה שמחזירה רשימה כלשהי של אנשי קשר נקרא לה "GetContacts" מפני שהפונקציה במהותה היא כוח עבודה שמחזיר ערך, היא בעצמה לעולם איננה מחזיקה ערך, אחרי שהיא מסיימת את העבודה שלה היא נעלמת מהמחסנית. לכן לפונקציה נקרא על שם הפעולה, ולמשתנה נקרא על שם הערך שהוא מחזיק.
הבה נעבור לדוגמאות:
נניח שיש לנו תלמידים שצריך להצמיד להם חונכים, אם למשל יש שגרה שתפקידה לצרף תלמיד לחונך, הייתי קורא לה: AttachStudentToTeacher למה? כי השגרה תפקידה רק לבצע פקודה, ולכן הכי נכון לקרוא לה כשם הפקודה שאותה היא מבצעת.
אולם אם יש אובייקט שמכיל את המידע אודות התלמיד והחונך, הייתי קורא לו כך: StudentByTeacher האובייקט הזה זהו שמו האמיתי והראוי לו, הואיל והוא מייצג את המידע הזה, השם הזה מתאים למיכל של מידע, שמכיל את המידע הרצוי.
ואם יש לי פונקציה שאמורה להחזיר לי ערך של תלמיד לפי מורה הייתי קורא לה: GetStudentByTeacher המילה Get (תמצאו את זה בלי סוף בפונקציות של מייקרוסופט) אומרת שאתה רק "מקבל" את הערך, אולם האובייקט הזה לא "מכיל" את הערך. וזה חשוב מאוד להבדיל בין אובייקטים לפונקציות.
מצד שלישי, לפעמים יש לנו פונקציה שעושה עבודה של שגרה, אולם היא מחזירה לנו True או False בסוף רק כדי שנדע אם הפעולה הצליחה או נכשלה מסיבות כלשהן כגון כללי אימות. במקרה כזה הייתי קורא לפונקציה בשם של שגרה AttachStudentToTeacher ולא בשם של פונקציה, וכל כך למה? הואיל והערך שהיא מחזירה איננו מכיל את המידע שהשם שלה מייצג, אלא את המידע לגבי הצלחת הפעולה שלה. ראוי להתייחס אליה כשגרה לכל דבר.
לפעמים ראוי לקרוא לשם שייצג את התוצאה של הפעולה ולא את הפעולה עצמה, למשל, נניח ויש לנו פונקציה שעושה בדיקה, האם עובד מסויים פנוי וזמין בשעה נתונה, הפונקציה מקבלת את ערכיה, עושה את עבודתה ומחזירה בסופו של דבר אמת או שקר, איך נקרא לפונקציה כזאת? CheckAvailabilityWorks ??? לא נראה לי, אני הייתי קורא לפונקציה WorksAvailable(שלא לדבר על כך שפונקציה זו אמורה להיות מאושכלת בירושה או שלא בירושה בתוך מחלקת עובדים אבל נניח לזה כרגע) למה? מפני שכאן הפונקציה מחזירה לנו ערך שמעניין אותנו, ומבחינתנו ראוי להתייחס אליה כאובייקט, כלומר פחות מעניין אותי כרגע מה היא עושה, ויותר מעניין אותי הערך שלה, האם העובד כרגע זמין. נמצאנו למדים, שפונקציה יש לקרוא לה על שם הערך שהיא מחזירה כאשר הערך הוא עיקר, ואילו על שם הפעולה שלה כאשר הפעולה היא עיקר מבחינתנו. (בשפות כמו C# המאפיין הוא סוג של הכלאה בין פונקציה למשתנה, ולכן זהו הכלי הכי טוב לעבודות מהסוג הזה)
ישנם שמות של מצבים הצמודים בדרך כלל למספרים או נוסחאות יחסיות: כגון מהירות, עוצמה, יעילות, וכדומה. כשנכתוב מדד כזה, בדרך כלל תהיה זאת פונקציה שתיקרא על שם הערך שהיא מחזירה, אולם פעמים שהיא מפעילה עוד צבא שלם של פונקציות סביבותיה, ועל כך נדבר בשיעורים הבאים שידונו בפיזור סמכויות.
נשתדל תמיד לקרוא לאובייקטים בשמות שאינם סמליים, אלא בשמות שהם בעלי משמעות שימושית מובהקת, אם אנו מדברים על עצמים, כגון מחלקות מאפיינים או משתנים, לא נבחר בשום אופן בשמות סמליים שבחרנו, "מחוסר ברירה" אלא נעשה מאמץ ונקרא להם בשמות שמשמעותם נובעת מתוך עצמם, גם אם זה יגרום לנו לאריכות יתר.
יותר קל לקרוא לאובייקט בשם, מאשר לפונקציה או שגרה ריקה שאינה מחזירה דבר, כי אובייקט, בסופו של יום ייקרא על שם המידע שהוא מכיל, ואילו פונקציה שעושה פעולה כלשהי, קשה לנו להגדיר מהי הפעולה שהיא עושה בדיוק, בפרט כשהיא חוליה בתוך שרשרת של פעולות. לכן ההמלצה שלי האישית, ככל שהשם יותר מעורפל, כך כדאי יותר לפצל את הפונקציה לפעולות בודדות נפרדות, על מנת להשיג בהירות בהפעלתן. זה גם יעזור לנו להבין טוב יותר את תפקידיהן השונים של הפונקציות שנכתוב.
מסקנא: שפה = בהירות מחשבתית. ולכן הארכיטקטורה האמיתית מבחינת איכות קוד, גלומה בשפה נכונה וברורה שאתם משתמשים בה.
בהצלחה לכולם ושנה טובה.
פורסם במקור בפורום CODE613 ב02/09/2013 17:10 (+03:00)
תודה על הקרדיט, תמיד שמחים לעזור...... 
פורסם במקור בפורום CODE613 ב15/08/2013 17:02 (+03:00)
אין לי אפשרות לעקוב אחרי הבעיה, מכיוון שהמערכת כולה הוחלפה, וכרגע הכל עובד כמצופה.
פורסם במקור בפורום CODE613 ב21/08/2013 20:15 (+03:00)
טוב כרגע האיש הטכני של הארגון החליט להחזיר את זה ל server 08 rt2 מכיון ש2012 לא הוכיח את עצמו, והם שינו את כל הגישה, וכל הטכנאים עצבניים על מייקרוסופט.
כך שאני ממתין לשבוע הבא, כי כרגע אין לי אפשרות לבדוק שום דבר.
פורסם במקור בפורום CODE613 ב15/08/2013 16:49 (+03:00)
שמעתם??
בן אדם רוצה להשתמש בקוד
File.Copy
File.SetAttributes
אשר המה בספריית System.IO
אבל כשמפעיל אותו ב win server 2012 הוא מפיל את הקוד! למה????
פורסם במקור בפורום CODE613 ב13/08/2013 14:40 (+03:00)
שלום
יצא לי בזמנו ליצור עם חבר DLL בדוט נט, אולם הוא היה זמין ל VB6 באופן פלאי. אינני זוכר כבר כמעט כלום מן התהליך.
אחרי חפירות מעט באינטרנט, אז אינני מעוניין כלל ועיקר ברישום ברג'יסטרי, וגם עדיף שלא לעשות רפרנס כלל בפרוייקט של VBA, אלא קריאה על ידי קוד בלבד לקובץ ה DLL כך שגם אם אין אותו לאחד הלקוחות, או באחד המחשבים, אני שולט על השגיאה, וזה לא תוקע את כל העולם.
אם יש איזה מדריך מסודר לנושא אשמח מאוד.
בברכה.
פורסם במקור בפורום CODE613 ב09/08/2013 15:20 (+03:00)
תודה למג'יק קוד על עריכת הקוד ונקיונו:
Public Function UnicodeEncode(str) As String
If IsNull(str) Then Exit Function
Dim i, a
For i = 1 To Len(str)
a = AscW(Mid(str, i, 1))
If a > -1 And a < 127 Then
UnicodeEncode = UnicodeEncode & "%" & String(2 - Len(Hex(a)), "0") & Hex(a)
ElseIf a > -1 Or a < 65535 Then
UnicodeEncode = UnicodeEncode & "%u" & String(4 - Len(Hex(a)), "0") & Hex(a)
End If
Next
End Function
:|
פורסם במקור בפורום CODE613 ב11/08/2013 18:50 (+03:00)