ניהול חלונות WPF
-
@דוד ל.ט.
אפשר לעשות טאב קוטרול, ובמקום חלונות להשתמש בטאב אייטמס.
אם רוצים לארח חלונות ממש, זה סיפור רציני שמצריך מציאת מחלקה מתאימה.זה פשוט מאוד, במקום חלון עושים יוזר קונטרול, אם אני מבין נכון אתה יכול להשתמש בו כפונקציונליות של חלון לכל דבר, והוא יכול להתארח בכיף בתוך טאב.
פורסם במקור בפורום CODE613 ב07/04/2014 13:36 (+03:00)
-
אז אם הבנתי נכון יש חלון עם TabControl
ובכל פתיחת חלון מאכלסים לתוך ה-TabItem את ה-UserControl,
בכותרת יש להכניס כפתור לסגירת ה-TabItem
הבנתי נכון?
נשמע פשוט ונחמד...
מה לדעתכם אכן כדאי להכנס לזה או להשאיר את המצב הנוכחי?!
משום מה נראה לי שתוכנה שפתוחים לה חלונות מרובים על המסך (כמו באקסס 2003) זה קצת מבלבל ופחות מתאים לפיתוח המודרני
אני צודק? ובכלל עד כמה שווה ההשקעה בפיתוח הויזואלי של התוכנה?פורסם במקור בפורום CODE613 ב07/04/2014 21:32 (+03:00)
-
המראה הויזואלי זה מאוד חשוב, וזה הרושם הראשוני שהלקוח מקבל עליך [כידוע ברזי הפרסום], תפתח משהו שתוכל לקחת אותו לכל תוכנה עתידית שתבנה משהו עצמאי וגנארי עד כמה שאפשר, כאילו זה היה חלק מהפרימוורק של מיקרוסופט.
פורסם במקור בפורום CODE613 ב07/04/2014 22:17 (+03:00)
-
@דוד ל.ט.
בעיקרון לסגור זה להסיר טאב קונטרול.
חייבים לכתוב לזה קוד מסויים.המראה הויזואלי זה מאוד חשוב, וזה הרושם הראשוני שהלקוח מקבל עליך [כידוע ברזי הפרסום], תפתח משהו שתוכל לקחת אותו לכל תוכנה עתידית שתבנה משהו עצמאי וגנארי עד כמה שאפשר, כאילו זה היה חלק מהפרימוורק של מיקרוסופט.
חבר'ה כמה פעמים כבר אמרתי, יש מחלקה אדירה שנקראת ChromeTabs שזה טאב קונטרול שנראה כמו כרום, מתנהג כמו כרום, ושם אפשר לפתוח חדש (ולארח בתוך הטאב יוזר קונטרול), לסגור, יש אפילו את האיקס הקטן הזה בצד שמאל של הלשונית שנהיה אדום עם ריחוף העכבר, הוא יודע גם להרחיב ולצמצם את הרוחב של הלשונית לפי הצורך, הכל בכל מכל כל,
וזה לשון גיט האב: A WPF custom tab control built from the ground up to mimic the user experience found in Google's Chrome browser.
עובד ב WPF בצורה מדהימה. כל מה שצריך זה לתת להם קרדיט. אין שום צורך לשבור את הראש בנושא הזה.פורסם במקור בפורום CODE613 ב07/04/2014 22:24 (+03:00)
-
הפקד שהזכרת באמת מרשים אבל אני אישית אוהב את הטאב קונטרול בסגנון של VS שהטאב איטמס לא משתנים ברוחב שלהם וכשלחלקם אין מקום המעבר אליהם מתבצע ע''י חץ קטן מצד ימין שפותח רשימה של כולם.
דבר נוסף שחסר בפקד הזה ביחס לכרום הוא גיררת טאב איטם החוצה ושיהפך לחלון חדש.
ועוד דבר אין שם איקון בראש כל טאב איטם כמו בכרום.פורסם במקור בפורום CODE613 ב07/04/2014 23:23 (+03:00)
-
הפקד שהזכרת באמת מרשים אבל אני אישית אוהב את הטאב קונטרול בסגנון של VS שהטאב איטמס לא משתנים ברוחב שלהם וכשלחלקם אין מקום המעבר אליהם מתבצע ע''י חץ קטן מצד ימין שפותח רשימה של כולם.
דבר נוסף שחסר בפקד הזה ביחס לכרום הוא גיררת טאב איטם החוצה ושיהפך לחלון חדש.
ועוד דבר אין שם איקון בראש כל טאב איטם כמו בכרום.זה השוואה ממש לא נכונה. הרי בכרום לא היית רוצה את השיפורים הללו, כך שאתם מדברים על שתי צרכים.
מה שאתה אוהב זה חלונות עם עגינה יש כמה פרוייקטים חינמיים כאלו בWPF, אני זוכר avalonDock.פורסם במקור בפורום CODE613 ב08/04/2014 11:22 (+03:00)
-
בסוף עשיתי טאב קונטרולים לבד ובסופו של דבר בגלל שישנה ביינדינגים לelementName שהוא בעצם שוה גם בכרטיסיות אחרות ממיילא כל התוכנה מסונכרנת יחד ונהיים שיבושים מטורפים
למישהוא יש פיתרון דחוף? (מדובר בתוכנה שכבר בנוייה כך שקשה לחשוב על דרך חזור)
מקוה שהסברתי ברור
תודה!פורסם במקור בפורום CODE613 ב26/05/2014 02:45 (+03:00)
-
בסוף עשיתי טאב קונטרולים לבד ובסופו של דבר בגלל שישנה ביינדינגים לelementName שהוא בעצם שוה גם בכרטיסיות אחרות ממיילא כל התוכנה מסונכרנת יחד ונהיים שיבושים מטורפים
למישהוא יש פיתרון דחוף? (מדובר בתוכנה שכבר בנוייה כך שקשה לחשוב על דרך חזור)
מקוה שהסברתי ברור
תודה!לכאורה יש כאן ניתוח לא נכון של תופעה.
element Name מוגבל לסקופ השורש הויזואלי של המופע שאותו הוא מייצג.
לדוגמה בחלון, ברמת החלון, ביוזר קונטרול ברמת היוזר קונטרול ואותו דבר סטייל וטמפלט.הבעיה כנראה שונה, אולי סנכרון בין הCurrentItem של מקור נתונים משותף.
פורסם במקור בפורום CODE613 ב26/05/2014 11:35 (+03:00)
