עוד באג שמביא את השגעת

מה קורה?
איזה יופי שאני פונה אל הבלוג שלי רק שפלקס מצליח לעצבן אותי יותר משקריסטל עצבנה ב"שושלת", הא?
ומה על הפרק היום? התנהגות לא ממש צפויה של ה-DataGrid (מה חדש?) שגרמה לי לאבד כמה שעות טובות, ולמצוא את Workaround הצולע משהו, אבל עובד.
בואו נתחיל מהסימפטומים: יש לכם DataGrid, יש בו Columns, ויש בו מידע. אתם לא מעוניינים שלחיצה על ה- header תבצע sort וגם לא מעוניינים לאפשר גרירה של עמודות וסידורן מחדש. לא כזה, בשמיים, נכון? לא כאילו ביקשנו... נאמר... לרקוד עירומים ליד הצנטרפוגות של אחמדיניג'אד, נכון? אז הנה באנו אל המלאכה, והגדרנו את ה- DataGrid, עם המאפיינים הבאים, כך:

draggablecolumns="false"
sortablecolumns="false"

כי מה? אנחנו פסיכים לרשום על כל עמודה אם היא ניתנת לסידור, אם זה גורף? וודאי שלא. קימפלנו והנה לנו הפתעה - ברגע שאנחנו לוחצים על ה header אנחנו מקבלים תופעה מעניינת - הבחירה שלנו ב DataGrid מתאפסת, כי מסתבר שלחיצה על ה header משחררת ListEvent.CHANGE. נכון שזה מרגש אתכם, כמעט כמו שזה ריגש אותי?
חפירה מהירה בעירמת אותיות שאדובה מכריזים עליה כקוד תגלה שיש תנאי פשוט שבודק, בין היתר, את שני המאפיינים הללו - ואם שניהם false, נחשו מה קורה? זה לא בכוונה, זה פשוט נראה כמו מקרה שלא טיפלו בו, אז ברירת המחדל צצה לה, ומאחר ש header הוא item לכל דבר, הא לכם התוצאות.
פתרון? יש, אבל לא ממש נחמד - מה שצריך לעשות הוא להגדיר מאפיין draggablecolumnsעל DataGrid, ואז להגדיר על כל עמודה שאסור לסדר אותה.
לכל מי שממש מתעניין ,פתחתי באג ב Flex Jira, אתם יכולים לעקוב ולהצביע עבורו - ממש כמו נינט, אבל עם הרבה יותר משמעות. זה ה Key שלו: SDK-15321.
חג שמח וכשר - אל תשכחו לפתוח את הדלת לאליהו הנביא ולהיות נחמדים לדודים ששוב שואלים "מה זה פלקס?"

Flex Messaging Consumer מדבר נגוע

מה קורה?
זה פשוט גובל בחוסר אחריות משווע, מה שקורה שם בדומנטציה של פלקס. הנה קחו לכם מקרה שגזל מעבדכם הנאמן זמן רב:
מנגנון ה messaging של פלקס עובד עם שני חברים טובים Producer, ואח שלו Consumer (ניתן לקרא עליהם באחד ה-PDF-ים היותר ארוכים שיצא לי להשתעמם מהם).
Consumer הוא בנדיט לא קטן, שכן אפשר להגדיר לו על איזה subtopics רוצים שהוא יאזין, ומעבר לכך, אפשר לסנן הודעות עפ"י מאפיין שנקרא selector, שהוא למעשה מסנן על ערך מסוים שנמצא ב-header של כל הודעה והודעה. כלומר אם בכל header אני אחזיק מפתח שנקרא לו issue, ואני אתן לו ערך לפי לוגיקה מסויימת, אני אוכל מאוחר יותר לסנן הודעות לפי המפתח הזה. את זה עושים בכך שנותנים ל-selector מחרוזת SQL-ית, שתפקידה להגדיר "פילטר" (או זה או זה או זה וכו'...).
ויודעים מה יותר מגניב? שאפשר לשנות את המחרוזת הזו בזמן ריצה מבלי לדאוג לסנכרון מול FDS, הכל יעשה מאחורי הקלעים ולנו יהיה צ'אט שעובד כמו סמיר שוקרי בחתונה ברהט.
כי... ככה כתוב בדוקומנטציה שלהם.
בלי לדאוג.
מאחורי הקלעים.

מאחורי אחותם!
מסתבר שזה עובד נחמד, לוקאלית, על שרת שיושב לך על הברכיים, אבל נסה עם שרת מרוחק... כינים. כן, מסתבר שזה מקרטע, והקטע הזה גורם לכל צ'אט שתבנו המשתמש במנגנון ה selector, לדדות כמו הומלס בסרט ערבי של יום-שישי. פתאום הודעות לא מגיעות, פתאום הודעות משום מקום צצות כמו רוחות רפאים. שימו עליי את שרשרת השום, כי אני נכנס לממלכת הוודו. מה לעשות, הא...?
או! שיש מה לעשות, והוא להכריח את ה consumer לעשות subscribe שוב, ואז זה עובד.
אני ממש לא נכנסתי כרגע לעומקה של בעיה, אם הרישום המחודש הזה יוצר בעיה אחרת בקטע של ביצועים, זליגת זכרון וכדומה, שיהיה... בכל אופן - זה עובד.
פסח כשר ומזל טוב
:).

Cusomizing the RadioButton label

סתם משהו קטן שיכול לפתור לכם הרבה דברים שאדוויל לא.
הדרישה?פשוטה לכאורה - תן לי קונטרול של RadioButton שהכתובית שלו (Label, יא קטנוניים) תתמוך ב-HTML.
הפתרון? גם הוא די פשוט למרות שלא ממש אינטואיבי, שכן RadioButton יורש את Button ושם נעשית כל מלאכת השמת הטקסט אל הכתובית, אבל זה מה שיעצור אותנו? כנראה שלא... אז מה עושים? יוצרים מחלקה המרחיבה את RadioButton ו- override למתודה הנחשית updateDisplayList, בה אנחנו נגדיר שאותו UITExtField של הכפתור ירונדר כ-HMTL:

/**
* Override the updateDisplayList to set the textField of the
* radio button to hold HTML taext in it
*/
override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void {
super.updateDisplayList(unscaledWidth, unscaledHeight);
textField.htmlText = label;
}

בקיצור, זה הסיפור. לא מסובך, נכון?

תבלו.