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

הבעיה שהדמו שלי הוא WINRT
אני ינסה לתרגם אותו

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

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

ומשום מה את כל הפלפול הזה הוא מנהיג אותו דבר גם כשיצרתי LIST לבד. ואפילו כשלא החלתי את המאפיין הרע הזה לחיובי.

פורסם במקור בפורום CODE613 ב19/05/2014 15:22 (+03:00)

אתה צודק..

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

פורסם במקור בפורום CODE613 ב19/05/2014 13:54 (+03:00)

למה אם מאפיין IsItemClickEnabled = true ב-GridView או ListView אזי אי אפשר לבחור אלמנטים רק על ידי מקש רווח או בטאצ' עם גרירה כלפי מטה של האלמנט

פורסם במקור בפורום CODE613 ב18/05/2014 14:26 (+03:00)

הבעיה היתה שלא שמתי לב בסך הכל שעשיתי ירושה ל- IList<T> ולא עשיתי ירושה ל IList
והבעיה היא שה-GridView מכריח לעבוד מול ILIST שינוי ג'נריק.

תודה בכל מקרה

פורסם במקור בפורום CODE613 ב16/05/2014 12:26 (+03:00)

מה פתאום!!!!!!
ודאי שאפשר ליצור את זה לבד... עשיתי ניסוי ועשיתי קוד דומה ל-observablecollection וזה עבד מצויין
יש לו איזה מאפיין שכנראה שכחתי להגדיר כיון observablecollection יורש מCOLLECTION כנראה ששם נמצאת הסיבה.
יש לי כבר אפליקציה שעובדת וניסיתי לראות את ההבדל ולא מצאתי.

פורסם במקור בפורום CODE613 ב16/05/2014 11:44 (+03:00)

public class ListGroupShapes : IList<GroupShape>, ICollection<GroupShape>, INotifyCollectionChanged
    {
        public event NotifyCollectionChangedEventHandler CollectionChanged;
......
}

עשיתי לבד collection עם כל מה שצריך הכנסתי במקור הנתונים של הGRIDVIEW כלסס מסוג הקולקשן הזה.

היה אמור להיות שבעת הוספת אלמנט לקולקשן יודיע לגרד שנוסף ויפעל בהתאם.

בפועל כשהוא בא להוסיף ואני מנסה לשלוח הודעה זה לא עוזר כיון שהוא לא משתמש באירוע של שינוי קולקשיין. ובבדיקה אני רואה שזה מחזיר NULL.

public void Add(object item)
        {
.....
......
//
            if (this.CollectionChanged != null)//זה אכן שווה NULL
            {
                var args = new NotifyCollectionChangedEventArgs(NotifyCollectionChangedAction.Add, item, tmpinx);
                this.CollectionChanged(this, args);
            }
        }

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

יש כלים שיודעים לקרא ולהציג FlowDocoment אבל אני לא רוצה אותם אלא רוצה לשלוט על החלוקה לבד.
הוה אומר שאני יכול לפרוס את הדפים כאלמנטים נפרדים.
ב-WINRT יש כזה דבר שנקרא RichTextBoxOverFlow שזה אומר, תיבת טקסט להמשיך את מה שלא נכנס בקודם. אקיצר לעצב עלון עיתון וכדו', ובWPF אני לא מוצא משהוא דומה,
-אני יודע שאני יכול לחשב לבד את מספר הפרגרפים ומקטעים וללמוד את כל חוקי הFLOWDOCOMENT ולבדוק את הגובה לפי כל שורה אני מוותר על התענוג-

תודה מראש

פורסם במקור בפורום CODE613 ב11/02/2014 11:20 (+02:00)

לא הבנתי מה הסתבכתם
בACCESS יש יצוא לSQL ישירות. הוא מייצר לך קובץ נתיב ואחכ אפשר להשתמש בו. ושם אתה מכניס את כל מה שאתה צריך.
פשוט ביותר

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

הפקודות שהצגתי בתחילת האשכול נותנות את התוצאה - ולגבי ה-ACTUAL הוא מתעדכן רק אחרי פעולת הARRANGE

ולגבי מה שדוד ל.ט שאל -
המקרה שלי הוא שהכנסתי TEXTBLOCK עם גלישה בתוך BORDER ואת זה הוספתי ל"דבק פנל" , ואת הפעל הכנסתי לתוך גריד ואת הגריד הכנסתי לתוך PAGECONTENT שבסוף נוצר לי מסמך של FIXEDDOCOMENT.

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

פורסם במקור בפורום CODE613 ב06/02/2014 23:41 (+02:00)

יש שתי פקודות ששניהם ביחד גורמים לחישוב המידות של האלמנט לפי מה שידוע לי:
uielemnt.Measure(new Size(?,?));
uielement.Arrange(new Rect(new Point(0, 0), ui.DesiredSize));
בפועל התוצאה של ה-DesiredSize יצאה יותר מכפי שיצא על המסך.
זה קרה לי ב-TextBlock שהטקסט גלש ורציתי לדעת כמה הגובה יצא, כפיתי את החישוב וקיבלתי את המאפיין הלז. ובדקתי גם את ה-ActualHigth ואכן יצא אותו דבר, אבל כשהגיע למסך הוא התקטן.
רציתי לבדוק במה הוא הקטין, אז הפכתי את תיבת הטקס לתמונה לפני שהגיע למסך ואז הדפסת את שניהם את התמונה ואת הרגיל וראיתי שיש לו שינוי במרחק בין שורות שעל המסך הוא החליט שמספיק פחות.

אם למי שהוא יש מושג בזה אני ישמח, כי זה אומר שאין אפשרות לדעת באופן בטוח את ה-ACTUALWITH שלא אחרי הצגה

פורסם במקור בפורום CODE613 ב06/02/2014 16:30 (+02:00)

אז זהו..

הבעייה היא בעצם רק לגבי LIST שDATACONTEXT שלו נמצא ב-CONTAINER שלו ולכן זה לא עובד אם זה לא רואה את המסך. לגבי שאר הפקדים בדרך כלל אפשר לגשת אליהם ישירות.

והפתרון פשוט שלדוגמא בTEXTBOLCK במאפיין DATACONTEXT שלו צריך להכניס
DataContext="{Binding DataContext, RelativeSource={RelativeSource TemplatedParent}}"
ואז אנחנו מרוויחים שמקור הנתונים נמצא ישירות בפקד ולא ב-PARENT. כיון שהצהרנו מפורש שיעתיק מההורה לילד.

מקווה שעזר למישהו

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

כרגע גיליתי כך.
כידוע DATABINDING מתייחס ל-DATACONTEXT הראשון שהוא מוצא בשרשרת, הוה אומר אם יש בילד DATACONTEXT מתייחס אליו ואם זה NULL הוא עובר להורה וכו'.

אבל....

כל זה במידה וזה מגיע לממשק אבל אם זה הולך ישירות להדפסה אז אפילו אם כופים INVALIDATE וכן MEASURE וכן ARRANGE הוא יודע להתייחס רק לDATACONTEXT של הפקד הנוכחי ולא מחפש בירושה.

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

פורסם במקור בפורום CODE613 ב02/02/2014 22:30 (+02:00)

שלחתי להדפסה VISUAL כל שהוא. שבתוכו יש קישורים של BINDING .

1. לא עבד הBINDING בכלל. ורק בהצגה על המסך זה עבד.
2. כשהשתמשתי בSTATICRESOURCES והכנסתי אובייקט בRESOURCES את אותו אובייקט שבDATACONTEXT וקישרתי אליו הכל עבד מעולה. (בעקרון היה אפשר לקבוע את הנתונים בקוד ישר אבל כיון שאני צריך את זה לTEMPLATE ןSTYLE מאד לא נוח לעשות זאת דרך הקוד).
3. דבר מוזר אחר שהכנסתי מערך לRESOURCE וקישרתי אליו LISTVIEW. ובאייטם הכנסתי TEXTBLOCK שהטקסט שלו מקושר בבינדינג לערך הנוכחי שבליסט. התוצאה היתה שהוא אכן הוסיף אייטמים לפי מספר האייטמים שבליסט שנמצא בRESOURCE אבל את הערך הוא לא הסכים להכניס לTEXTBLOCK.

היוצא מכאן שאם הפקד לא מגיע למסך לא עובד בכלל הBINDING ואפי' אם מקור הנתונים הוא בתוך ה-RESOURCES לא יעבוד.
ודרך אגב לא לדאוג אני לא משתמש בפנל וירטואלי אלא ב-WRAPPANEL.

פורסם במקור בפורום CODE613 ב02/02/2014 21:08 (+02:00)

דבר ראשון אכן הצורה שמיקרוסופט הועידה זה כמו שהביא רחמים...

אבל אפשר גם בדווקא לבדוק את כל מחלקת המסך וכדו' אכן ב-WPF זה מסובך ולא שבWINFORM זה היה יותר פשוט, שם לא היה יותר מדי אפשרויות.
בקישור הזה הוא משתמש במחלקות שמטפלות בנקודה הזאת.

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

אתה שואל או עונה????

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

נא לשים לב גם למה שאתה צריך.
כי פונקציה בSQL לא תעזור לך צריך לעורר אותה באיזה שהוא מקום. הויה אומר או הטריגר בעת עדכון השדה או בCHECK (ב-CHECK אי אפשר להכניס פונקציה צריך לכתוב אותה ישירות ובתנאי שהיא אינה מכילה הפניות מבחוץ לשדות הטבלה).
החסרון שלא יהיה לך משוב ללקוח בזמן ריצה, אתה תקבל שגיאת SQL ותצטרך לקלוט את זה בCODE ולנסות לפענח בזמן ריצה, כמו שכתב לך דוד ל.ט
הרעיון לעשות זאת בצד שרת הוא רק לגבי חיפוש וחיתוך נתונים, אבל כאן למה שSQL יהיה יותר טוב מ-NET להפך קוד NET הרבה יותר מהיר וגם יותר גמיש, ובכל מקום מיקרוסופט מכריזים על זה שמבחינת ביצועים של חישוב הNET הרבה יותר מהיר.
זה מאד תלוי איך שבנית את הפרוייקט,
יש עוד סיבה לחשב דברים בשרת זה רק אם השאלה להוריד טבלה עם כמה עמודות ולעשות להם חיבור בקוד או להוריד עמודה אחת ולחשב אותה בשרת, אז אכן עדיף בשרת לפעמים, אבל כאן זה לא יעזור לך כלום, ולהפך, ושוב מאד תלוי בקוד שלך.
לפי איך שזה נראה אצלך אתה צריך ליצור אובייקט שמכיל כל מיני סוגי בדיקות אימות נתונים ולהחיל אותו על הTEXTBOX בירושה וכדו', והכניס לו במאפיין כל פעם בהתאם לצורך לאיזה סוג בדיקה הוא שייך בטופס הנוכחי.

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

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

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

כיון שלגבי פיענוח DOCX במהלך היווצרות אשכול השו"ת הושגה ההבנה שכנראה אין אפשרות הדפסת DOCX ללא תוכנה (עריכה אפשר על ידי OPENXML) אז הועלתה אפשרות שהשרת (מדובר פה על מחשב שרת שבו נמצאת התוכנה) יקבל קובץ PDF ולא DOCX ואז אולי לחבר ADOBE יש DLL שנותן להדפיס קובץ PDF בלי תוכנה. ובנוסף כיון שהשרת יקבל קובץ PDF אז תהיה בעיה לערוך את הקובץ, אז אם אני לא טועה יש להם גם אפשרות לערוך טקסט בצורה בסיסית. (אני בסך הכל צריך לשתול כמה מילים).
בכל מקרה אם משהוא מצא תוכנה שיודעת להדפיס קובץ DOCX אז ודאי ודאי שאני יותר ישמח. ואל נראה לי שיש דבר כזה כי אחרת יקומו חברות מתחרות לOFFICE שישתמשו בDLL ויוסיפו פונקציונליות משלהם.

פורסם במקור בפורום CODE613 ב01/02/2014 19:13 (+02:00)

אוהאו 4 דוגמאות! משהוא כאן עבד קשה....

אבל...

2 הדגומאות האחרונות לא רלוונטיות כיון שהם משתמשות ב-INTEROP שזה עובד על ידי פתיחת ה-WORD בפועל.

2 הדוגמאות הראשונות זה נחמד מאד מישהוא באמת התחרפן וניסה ללמוד את הקוד, אבל מדובר על עיצוב ברמה פשוטה, אני מעוניין בהמרה גבוהה.

אני עדיין משוכנע שיכול להיות שיש את זה לחברת ADOBE שלתוכנת ה-ACROBAT שלהם (הקורא PDF הנפוץ) יש DLL מיוחדים ל-NET ואיתם אפשר אחרי שהמשתמש מתרגם בעצמו לPDF אפשר לערוך את הטקסט של קובץ הPDF.
עדיין זה נראה לי לא רעיון הכי טוב כי בדרך כלל המרות PDF שהם כוללות עריכת טקסט יש שיבושים בעיצוב, בטח כבר נתקלת בזה שיש אפשרות לשני סוגי המרה לPDF בכל אופן פעם זה עוד היה נראה לי שהיום זה אחרת.

פורסם במקור בפורום CODE613 ב31/01/2014 08:25 (+02:00)