פותחים-רואים :: Spacer

ראשית, הקדמה:
הפוסטים שיפתחו במילים "פותחים-רואים" למעשה יתארו נושאים בצורה הרבה יותר פרטנית, חודרנית (מי מחייך?) ופשפשנית. מה שהחבר'ה נוהגים לקרוא לו: Under The Hood, אבל כמובן אנחנו, שגדלנו על הגשש ומוכסכניקים מפוייחי-ידיים, לא יסמאו את עיניינו עם מושגי-שפר אמריקאים. יש? לעסק...
Spacer היא קומפוננטה קטנה שכל היעוד שלה בחיים הוא כזה: לעשות רווח (מפתיע, אני יודע). משתמשים בה בעיקר כאשר רוצים לעשות... רווח.
אוקיי, אני חושב שזה מספיק.
בכל אופן, אם נסתכל מעט פנימה נראה שכל מה שה Class שנקראת Spacer עושה היא להרחיב את UIComponent. זהו.
לא באמת... זהו.
עכשיו, מה שיותר מעניין היא השאלה "מה הוא ההבדל בין שימוש ב UIComponent במקום Spacer?". לכאורה, התשובה אמורה להיות "שום דבר", אבל לא ממש.
ניסוי קטן בהשוואה בין השניים מניב את התוצאות הבאות: 100Bytes~ לטובת השימוש ב UIComponent (כלומר, שמשתמשים ב UIComponent התוצר קטן יותר בנפח). כעת, יש את אלו שיגידו ש"מה זה 100 bytes?", אבל תחשבו על זה ככה - 10 Spacers נהיה כבר Kb... לא נעים, לא חבל?
תכלס? לא כזו רעידת אדמה, אבל שורה תחתונה היא, למה לא תשתמשו ב UIComponent במקום? חבל על כל טיפה.

DateField.selectedDate נותן בצנרת

זו לא סתם גסות, זו האמת לאמיתה.
מדובר כאן בבאג די ידוע שמצליח לגזול לי שוב ושוב דקות יקרות מכיוון שבכל פעם זה נראה לי כל כך לא נכון מכדי לקרות, אבל בכל זאת... התרחיש הוא טריוויאלי לחלוטין:
יש לנו DateField ואנחנו רוצים לחבר אותו ב binding אל תאריך שנמצא במודל שקר-כלשהו, בשאיפה (לגיטימית) שברגע שזה ישתנה, כך גם תשתנה הבחירה בלוח-שנה החמוד שנפתח מה DateFeild. שאיפה? חצבת! אני משנה ושמשנה את התאריך אבל הלוח-שנה לא מסמן דבר וחצי דבר. מקומם... מקומם מאד.
אז עשיתי חיפוש מהיר, גם כי זכרתי שכבר נתקלתי בתלאה הזו בעבר, והנה גיליתי את המיקום של הבאג ב Jira של פלקס, שכן זה באג ידוע (וסגור כבר בגרסה 3, להבנתי), שאם לא מאפסים את השעות, דקות ושניות של אובייקט ה Date, ה DateField פשוט לא מתייחס לזה. פשוט כך.
ניסיתי לחפור פנימה ולראות מה בדיוק קורה שם, אבל נתקלתי בביקורת גבולות עקשנית בדיוק לפני המחלקה: CalendarLayout. אם מישהו מצליח לחפור אליה, שלחו לי פנס ומפה.
זה בעצם העניין. אם אתם רוצים שלוח-השנה יתעדכן, יש לאפס את השעות, דקות ושניות של האובייקט. ולכל מי שאומר "אבל אתה בעצם משנה את ה timestampe של התאריך", אני אשיב: "אתם לגמרי צודקים, פלקס זה כיף".
שמחות.

DataGrid.selectedItem לא חבר של sort.

מה קורה?
בלי להאריך יותר מדי, קבלו באג שיכול היה להסיר שיערות מהחזה של אריק זאבי:
יש לכם DataGrid ואתם רוצים שתמיד האיבר הנבחר בו יהיה מסונכרן עם זה שנמצא לכם ב data model, כל שיהיה. בשביל זה אנחנו נשתמש ב Binding, נכון? ודאי. אבל למה אנחנו נחווט אותו? נחווט אותו למאפיין החבוי של ListBase (מאבותיו של DataGrid), הידוע בכיניו SelectedItem. זה נכון ש DataGrid לא נותן לנו אותו אפילו ב code hinting, אבל שועלי קרבות שכמותנו, לא נחפור ונגלה אותו? הרי זה די מתבקש, שיהיה מאפיין שאפשר להגדיר דרכו מי האיבר הנבחר תמיד, לא?
לפלקס יש הסיבות שלו ואני לא תמיד מבין אותן אבל בהחלט מכבד :).
הבעיה מרימה את קודקודה המעוות כאשר אנחנו משתמשים גם ב sort על אותו DataGrid אומלל. שכן אם נחפור עוד יותר בקוד של ListBase נגלה ש SelectedItem לא ממש אוהב לשחק דוקים כשיש sort על ה DataProvider של ה DataGrid. התוצאה היא מחזה מרהיב: בוחרים איבר, ה SelectedIndex נבחר אף הוא (שמתם לב? Index, לא Item), אבל כאשר עושים sort ה selectedItem משתנה אבל ה selectedIndex נשאר כשהיה. מה זה אומר? שבעצם לא השתנתה הבחירה למרות מה שאנחנו רואים... יש יאמרו פאטה-מורגנה, יש יקללו. ואם לא השתנתה הבחירה, אז כל המנגנון שווה לתחת, אם לנסח בעדינות.
אז מה עושים? דבר ראשון, שלא תעיזו להשתמש ב selectedItem כאשר מדובר ב DataGrid. זה לא נכון, זה לא נתמך ואתם תשלמו על זה, האמינו לי.

דבר שני, כל מניפולציה על DataGrid selection צריכה להתבצע דרך ה selectedIndex שלו. איך עושים את זה בדוגמה שהבאתי? הנה דוגמית קטנה....
טוב, רציתי להדביק פה קוד בצורה נורמאלית, אבל בלוגר לא ממש מפרגן - אני אמצא דרך ואחזור אליכם...
מצאתי :), בבקשה:

<?xml version="1.0" encoding="utf-8"?>
<mx:Application
xmlns:mx="http://www.adobe.com/2006/mxml"
layout="vertical"
creationComplete="initMain();">
<mx:Script>
<![CDATA[
import mx.events.CollectionEvent;
import mx.collections.Sort;
import mx.collections.SortField;
import mx.collections.ArrayCollection;

private var _aItems:ArrayCollection;

[Bindable]
private var selectedItem:Object;

private function initMain():void {
//create data for test
aItems = new ArrayCollection();

for (var i:uint = 1;i <= 10;i++) {
var obj:Object = {sort1:i,sort2:i*-1};
aItems.addItem(obj);
}
selectedItem = aItems.getItemAt(2);
}

private function set aItems(value:ArrayCollection):void {
_aItems = value;
setSelectedItem();
}

[Bindable]
private function get aItems():ArrayCollection {
return _aItems;
}

private function setSelectedItem():void {
if (aItems != null && selectedItem != null) {
for (var i:int = 0; i < this.aItems.length; i++) {
if (aItems.getItemAt(i).sort1 == selectedItem.sort1) {
dgItems.selectedIndex = i;
break;
}
}
}

}

private function refresh():void {
var newDP:ArrayCollection = new ArrayCollection(aItems.source);
newDP.sort = aItems.sort;
newDP.refresh();
aItems = newDP;
}
]]>
</mx:Script>

<mx:DataGrid
id="dgItems"
width="75%"
height="75%"
dataProvider="{aItems}"
updateComplete="setSelectedItem()"
change="selectedItem = dgItems.selectedItem">
<mx:columns>
<mx:DataGridColumn headerText="Sort 1" dataField="sort1"/>
<mx:DataGridColumn headerText="Sort 2" dataField="sort2"/>
</mx:columns>
</mx:DataGrid>

<mx:HBox width="75%">
<mx:Button label="Refresh" click="refresh();"/>
<mx:TextArea
id="output"
text="{dgItems.selectedIndex}"/>
</mx:HBox>

</mx:Application>

מיקרוסופט... שיהיו בריאים.

פעם, די מזמן למעשה, מקרומדיה החליטו שהשפה ה"אומללה" משהו שהם קוראים לה Action Script חייבת להיות מעוגנת באיזשהו סטנדארט, כך שלא יוכלו לקרא לה יותר, "הפרוצה של שפות התוכנה" ושאר כינויי הגנאי של ג'אוואיסטים-אפורים. אז מקרומדיה אימצה את התקן ECMA-4 (שבזמנו הוציא לנו את המעיים עם כל ה"מה זה private?) והנה AS החלה להזקוף גב, להרים סנטר ולהרגיש כאחת העם.
אז זהו... שלא ממש נכון לחדשות הבאות. התקן ECMA-4 נדחה ע"י IE.
למה נדחה? זו כבר שאלה יותר מעניינת, שכן אתם ודאי מבינים שמאז שפלאש תפסה תאוצה, מיקרוסופט מתנהגת כמו רעמסס ומנסה להתחכמה לו, ויעבידום כמו שנאמר בטיט ובסטנדארט ובאינטרנט-אקספלורר. זה פשוט בזיון, אבל כנראה שכך שומרים על מונופול.
מה שקרה הוא שמיקרוסופט תבעו, והתעצבנו וכו' והנה הוציאו את התקן הזה אל מחוץ לאינטרנט אקספלורר שלהם, וזה לא נתמך שם ו... כל העבודה של מקרומדיה/אדובה ירדה, פחות או יותר, לטמיון. נו שוין.
בואו, תקראו את הכתבה פה: מיקרוסופט עושה שרירים.
מישהו רוצה לשנות הימורים לגבי איזה אחוזי אימוץ יהיו לסילוורלייט?

שוב המציאות גוברת על הווירטואליה

תכלס, גוברת, אבל את מי זה מעניין.
שורה תחתונה היא שאני לא כותב כמו שהייתי כותב. אז אתם אומרים, ובצדק, שלפחות אתם מקווים שיש איזה תירוץ מספק. נכון! יש.
מעבר לעובדה שהעבודה נוטלת ממני יותר שעות ויותר משאבים, לאחרונה הצטרפתי להרכב (אם היינו בני 16 היינו קוראים לזה "להקה", אבל היום זה "הרכב") מגניב ויש שירים שאפשר לשמוע ויש אפילו וידאו. אז בזמן שאתם תרים אחר פתרונות קוד מרתקים, תבקרו גם פה: mySpace, וגם פה: YouTube.
דברים יותר משעממים בקרוב... :).