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

@רחמים

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

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

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

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

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

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

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

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

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

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

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

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

אגב, לפי מה שקראתי, ההשמה למאפיין State עושה גם קישור בעקיפין כך שהשורה של הקישור מיותרת.

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

מוצאים את השורה המתאימה משנים ושומרים ככה:

DbContext.SaveChanges().

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

בשביל לקשר כותבים:

DbContext.Attach(Entity)

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

לא הבנתי. שמירה רגילה?

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

@רחמים

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

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

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

מחלקה היא מצביע לכל דבר.

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

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

Structure עשוי להיות הפניה לפי ערך. השמה שלו היא למעשה העתקה, וממילא אין דרך להחזיק התייחסות אליו.
ייתכן שיש דרך ע"י מצביעים, אני לא בטוח, אבל בכל מקרה הנחיות בתכנות הם ש[u:dxpie7is]לא עושים בכזה מקרה Structure.[/u:dxpie7is]

הנה הכללים (של מקרוסופט) מתי לעשות Structure, אני פשוט תרגמתי מפה Choosing Between Class and Struct:
[list:dxpie7is]

1. המבנה מייצג לוגית ערך בודד.
2. סך הזיכרון של השדות עד 16 בתים.
3. [u:dxpie7is]בלתי ניתן לשינוי[/u:dxpie7is] זה בשביל "למנוע אי הבנות ובאגים".
4. לא אמור לעבור Boxing (המרה להתייחסות) לעיתים קרובות.
   [/list:u:dxpie7is]

בכל מקרה אחר יש להשתמש במחלקה.
ראה גם: http://programmers.stackexchange.com/a/92369/112215

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

הClear לא עשוי בדוט נט לניקיון אלא פשוט להחזיר את כל ערכי המערך למצבם התחילתי.
בעיקרון מבחינת המתכנת צריך לדאוג שאין רפרנסים חיים לאובייקטים מיותרים.
לדוגמה אם יש אובייקט ענק ושדה שלו בשימוש איזה אירוע זה מונע הריסה של האובייקט, זה תחום אחירות המתכנת. כל השאר זה דאגה של ה"אוסף הזבל" של דוט נט.
אבל במידה והמשתנה הוא בסקופ של פונקציה לדוגמה, אין צורך אפי' לאפס אותו, סוף התחום שלו הרוס אותו וממילא המידע שלו "יתום" וככזה הGC - "אספן הזבל" מוחק אותו [u:3n26xzb3]מתי שהוא[/u:3n26xzb3].
בתכלס תוכל לראות שאם תעמיס אלפי מגה, מידי פעם תהיה "מחיקה" מסיבית, משא"כ במגה בודדים (מתחת למה שהוקצה לתוכנית מלתכחילה) מסיבות חיסכון בביצועים כנראה הGC לא עושה כלום.
אפשר לאלץ את הGC לאסוף ככה: GC.Collect, אני חושב שזה לא מומלץ ולא יודע למה זה משמש, תוכל לראות שזה עשוה את העבודה באמת בצורה דרמטית מבחינת הזיכרון.

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

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

@רחמים

אז זה כמו ILSRY והרפלקטור ודומיהם ?

זה כמו שתשאל אם תת חובה ותת מקלע זה אותו דבר.

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

@רחמים

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

מה זה האיקסים?

הXXX מסמלים את מה שאני לא יודע.
מה שאני יודע פירשתי.

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

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

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

זה תלוי בהגדרת הVertivalAlignment, ובסוג האלמנט המכיל.
לדוגמה אם המיכל הוא StackPanel אז הוא תמיד מכווץ את האלמנט למינימום (גובה מפורש או MinHeight).

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

זה נקרא פעולות על סיביות.
הסיביות זה סדרה של בולאינים - כן/לא.
כשרוצים לתת הרבה אופציות לקבוצת בתים אחת (בית זה 8 סיביות) משתמשים בEnum מיוחד שמאפשר לתת ריבוי ערכים של כן לא (8 לכל בית).
(כתבתי על זה בעבר פה: http://tchumim.com/post/1236).

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

לדוגמה:

0 0 - האם לקריאה בלבד? בשתי המקרים לא.
1 0 - מסותר
0 0 - מערכת
0 0
1 1 - תיקיה
...

זה דוגמה שהעמודה הראשונה זה הקובץ והשניה זה האפשרות תיקיה בלבד דלוקה (FileAttributes.Directory). השוואה בינהם תניב שלילי בגלל האפשרות מוסתר שדלוקה במקור. מה שאנחנו רוצים זה לבודד את הדיקה רק על האפשרות תיקיה האם היא דלוקה, איך נבדוק זאת?
אז פעולת הAND (יש גם OR, XOR, NOT) עושה ככה, היא מחברת את שתי העמודות - מדליקה רק אם בשתיהם היה דלוק. זה מאפשר לבדוק את כל האוסף כולו כי כל האפשרויות הלא רלוונטיות סוננו ע"י הAND.

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

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

כמו"כ ראיתי פה רעיון חילופי לכל זה - להשתמש בתיקיית "שלח אל" כאן: %APPDATA%\Microsoft\Windows\SendTo.

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

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

עליך להוסיף Setter (שורה מעל Style.Trigger) שמגדיר את הIsEnable לשלילי.
(אל תגדיר זאת ישירות בכפתור, כי אז זה ידרוס את הטריגר).

פורסם במקור בפורום CODE613 ב31/03/2014 19:30 (+03:00)

System.IO.Path.GetName(@"C:\1.23.txt")

המחלקה Path מכילה הרבה פונקציות סטטיות שימושיות, כדאי לסייר.

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

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

פורסם במקור בפורום CODE613 ב31/03/2014 19:49 (+03:00)