נ
אנגולר וVS הולך מצוין ביחד, גם ההשלמה האוטמטית וכו'.
אבל עם ריאקט - לא הצלחתי לסדר סביבת עבודה נוחה כמו שצריך, עם באבל וכו' ושיהא טוב וכו'.
האם משהו עבר בדרך הזו מקודם והצליח לשבת יפה עם ריקאט בVS ויכול להמליץ מהניסיון,
או שזה פשוט טעות בכתובת וטכנלוגיות מהסוג הזה צריכות לעבוד בnode , npm.
פורסם במקור בפורום CODE613 ב23/01/2017 09:17 (+02:00)
יש לו אווסט חינמי.
זה לא עושה משהו רציני כלל חוץ מקריאה מקובץ טקסט ואיזה חיפוש והחלפה במסמך וורד פעיל.
הוא פשוט לא פותח לו את זה עד שהוא מנטרל את האנטי וירוס.
הוספה:
מברור נוסף עולה כי כנראה גוגל אשם בזה.
שלחתי לו את זה במיל והחלפתי המקודה של שם הקובץ בקו תחתי אמרתי לו להלחיף את הנקודה בקו.
אחרי זה התברר שגימייל הוסיף לש הקובת את הסיומת bat מעצמו, וכנראה עשה שם עוד דברים בדרך ולכן הוא עושה בעיות (עליתי על זה מלקוח אחר ששאל אותי הרי יש כאן נקודה).
כמו כן, פעם היה לי איזה קובץ bak של דטהבייס SQL, והוא לא נפתח לי, ומשלל העצות שלקטתי אז היה גם שכתבו בסטאק שמכיון שזה עבר בגוגל דרייב זה כבר לא אותו דבר ולכן יש קבצים רגישים שנפגמים שם. ידע הציבור ויזהר.
פורסם במקור בפורום CODE613 ב15/01/2017 22:33 (+02:00)
מה שכתבתי על אסקטנשיינס, התכוונתי לטיפוס החדש שעשיתי, שלא אצטרך כל פעם להכניס אותו אישית לפונקציה כדי לבדוק אותו. לא בסינטקס של לינק. אבל עדיין עם foreach אין לי גישה ללפני ואחרי מבחינת האינדקס. וגם הכתיבה צורכת התניות של ראשון ואחרון. עם for אני יכול לגשת לקונסטקטור בשקט בשורה אחת. אם זה היה עם foreach לא היתה לי גישה ישירה כפרפרוטי לקודם.
public IEnumerable<mypara> GetAllParas(word.Document doc) {
for (int i = 1; i <= doc.Paragraphs.Count; i++)
{
yield return new mypara(doc.Paragraphs[i], i == 1 ? null : doc.Paragraphs[i - 1], i == doc.Paragraphs.Count ? null : doc.Paragraphs[i + 1]);
}
ובאמת הוא אותו דבר, שגם "נצרך" על ידי המערכת רק ברגע הסינון הסופי של התניות.
פורסם במקור בפורום CODE613 ב25/12/2016 12:43 (+02:00)
מצוין, זה ממש פתח כפתחו של אולם. מרחיב לחלוטין את לינק. אבל במקרה שלנו אני אהיה חייב לא להתשמש באוסף כמות שהוא אפ' שאפשר לעשות עליו לינק, מכיון שאני רוצה ליצור ממנו טיפוס חדש שמכמס בתוכו את הפסקה לפני ואחריו וnull אם אין משהו לפני או אחרי, וא"כ הגם שforeach עם yeild יתן לי את האוסף כמו שהוא, אבל עדיין לא יהיה לי גישה לאברים לפני ואחרי(אא"כ סקיפ וכו'), ולכן אני משתמש בFor, גם עם yeild , וככה יש לי גם גישה לאינדקס, ולהכניס לקונסטרקטור את הפסקאות לפני ואחרי, וגם את האקטסנשיין, מכיון שהם לא פועלות על הפסקאות עצמם אלא על הטיפוס החדש, צריך לכתוב על הטיפוס החדש ולא על טיפוס הפסקאות של וורד.
פורסם במקור בפורום CODE613 ב25/12/2016 11:12 (+02:00)
ישר כח גדול!
אין אפשרות לגשת ישירות לאוסף הפסקאות בלינק. משהו כזה לא עובד:
var test = doc.Paragraphs.where(p=> p.Text=="tt")
וגם אי אפשר להמיר את זה לליסט לא ידני - אבל בהחלט לעבור על זה בforeach עובד גם עובד! (היה מונח לי בראש משום מה שרק מה שאפשר לעבור עליו עם foreach סובל לינק, והפוך, אבל אני מבין כרגע שזה לא תלוי זה בזה לגמרי).
ושוב תודה!
פורסם במקור בפורום CODE613 ב25/12/2016 01:31 (+02:00)
תודה רבה! אני עדין באמצע לעכל את כל העושר התכנותי שמתעופף כאן בנדיבות.
כפי מה שהבנתי מהקוד, כל הענין בנוי על yeild שהוא בעצם מאפשר לנו להפסיק כל לולאה או כל אינומרבל ברגע שאנו לא צריכים אותו יותר, וכן ליצור אותו רק כשצריך. כמו כן זה עובד על זה שחלק מהאופרטורים של לינק עובדים על זה ג"כ שהם לא נקראים עד שהם נצרכים ובינהם Where. לכן נוצר מצב בו אני יכול להצהיר על אינוברבל, במקרה הזה הפסקאות עצמם, והיצירה שלו תהיה "באוויר" עד שיצטרכו לעשות איתו משהו, וזה ההפעלה של התנאים, ואז שעוברים עליו בפעם הראשונה, בכלל זה "לוקחים" בחשבון את התנאים, ולכן יוצא שהמעבר הוא רק פעם אחת.
אבל אם כן, לא הבנתי, למה צריך את yeild בפעם הראשונה. הרי בין כה וכה נצטרך לעבור על כל הפסקאות כדי לעבור עליהם כדי לראות אם הם מקימים את התנאים, ונמצא באמת אף פעם לא מופסק באמצע היצירה של האינמרבל. אבל אם היה תנאי עצירה למשל של רק כמה פסקאות במספר מסוים אז אני מבין מדוע היה צריך את זה כדי שלא נעבור על יותר ממה שצריך.
וגם, מה יהיה הדין אם נצטרך להשתמש באופרטורים "חמדניים" כמו ספירה או מינמום, אז באמת הכל יצטרך להתבצע מיד, ותנאים נוספים יתנו תוצאות שקריות מכיון שהאוסף עבר מניפולציה כלשהיא.
List<string> ms = new List<string>() { "1","2","545","5445", "reewe" ,"qerwqerqwewrrwer"};
IEnumerable<string> result = ms.Where(o => o.Length > 3);
int num = ms.Where(o => o.Length > 3).Count();
ms.Add("erwereeweweweeeeeeeesdsddddddddd");
foreach (var t in result)
{
Console.WriteLine(t);
}
Console.WriteLine(num);
הקוד הזה יחזיר 4 תוצאות, אבל ספירה של 3.
ובר מן דין , אין לי אפשרות להעביר את אוסף הפסקאות למשהו אינמרבל, כיון שהוא לא מקיים את האינטרפיס, ועל כן אני חייב לעשות את ההמרה הראשונה לאינמברל ידני לליסט.
וענין הפרדת הקוד סריקה והקוד תנאים, אני משתמש בדיקצנרי, שצד אחד שלו זה קלט מהתמשמש, סטרינגי בדרך כלל והצד השני שלו זה Func.
לכל תנאי כזה יש דיקצנרי משלו עם הפעולות שלו, ולחלקם יש פשוט return true אם לא נבחרה אופרציה מסוימת. אחרי זה אני משרשר אותם יחד ומפעיל. וככה זה יותר מופרד יחסית, כי בסריקה אני רק מציין לדלגציה שמופיעה בדיצקנרי. (וכדי לחסך בזמן אני רוצה שטעינה של המילונים תהיה אסנכורנית).
פורסם במקור בפורום CODE613 ב24/12/2016 22:14 (+02:00)
תודה רבה על כל העצות - וכולנו זכינו כאן להרבה דברים טובים, אמנם לצערי במקרה הזה בכלל אין לינק.
מדובר על פסקאות של מסמך (וורד או אינדיזיין), ושם אין IEnumerable. (וגם לא עוזר המרה, כי הוא לא מקיים את האינטרפייס) ולכן צריך לסרוק אותם אחד אחד, והפתרון הראשון יותר תואם מבחינת הלולאה. אך דא עקא שזה באמת לוקח הרבה זמן, וגם באמת אני צריך גם את מה שלפניו עם כמה וכמה תנאים וגם אם מה שאחריו וכמה וכמה תנאים, וכמובן גם אותו, עם כמה וכמה תנאים, כולם שונים אחד מהשני . (חשבתי את התנאי הקשור לפסקה המרכזית אוכל בנקל להכניס ללינק והיה חסר לי הענין של האינדקס). ובאמת הוספתי לטיפוס המרכזי אקסטנשן כדי שיהא יותר נח לכתוב, אך גם בזה יש מתודות אבל לא פרופרטיז.
אז כדי לחסוך בזמן בניתי מחלקה עוטפת מותאמת אישית של PARA, ולה יש PROP של current, next, prev בהתאמה.
ומטעמי חסכון אני עובר בלולאה אחת על הכל, ואם מצאתי משהו בתנאי המרכזי, כלומר בפסקה בנוכחית, אני מכניס אותו, ואת הקודם לו ואת הבא אחריו לאובקיט, ועושה מהם ליסט חדש.
על ליסט, יש לינק, ואז זה ממש PROP רגילים שעושים עליהם לינק בלי קשר למקום שלהם ברשימה. ואחרי זה אני מפעיל את האופרציה הנדרשת על הרשימה המסוננת מכל וכל. ככה גם הקוד קריא יותר, כי לשים באותה לולאה גם את התנאים על כל שלושת החברים עושים בלאגן גדול.
פורסם במקור בפורום CODE613 ב22/12/2016 00:04 (+02:00)
האם יש דרך לפנות בLINQ לאינדקס אחר באותה רשימה? כלומר אני מחפש אוביקט שהתנאים הבוליאנים יתקיימו לפניו ולא עליו עצמו. נניח שאני מחפש אוביקט הבא אחרי אוביקט אחר שיש לו PROP של 3 נניח. זה אמור להיות משהו כמו
var obj = myList.Where(p => p.index-1.prop == 3)
פורסם במקור בפורום CODE613 ב21/12/2016 00:28 (+02:00)
יש לי טבלה של מוצרים שאני רוצה להכניס לה נתונים, ולהוסיף מוצר.
הענין הוא שלכל מוצר יש מאפיינים, נניח צבע.
אני מבין שמחמת חוקי הנרמול צריך לעשות טבלה מקשרת ולא לרשום לכל אחד את הצבע שלו בפרט כאשר יתכנו כמה צבעים.
ולכן עשיתי טבלה נוספת לצבעים שלכל צבע יש ID, ועוד טבלה נוספת שמקשרת בין המוצר לצבע. יתכנו כמה צבעים לאותו מוצר.
הבעיה היא, שעשיתי SP שמוסיף מוצר חדש ואני רוצה לעדכן את הצבעים שלו בטבלה המקשרת.
הענין הוא שהID של המוצר ניתן אוטמטית, ואין לי אותו ברגע שאני מפעיל את הSP של הוספת מוצר חדש. איך אני יכול לעדכן אותו בכל זאת.
כרגע מה שיש בידי זה רק INSERT פשוט.
פורסם במקור בפורום CODE613 ב28/11/2016 11:30 (+02:00)
מתעורר לחיים לא הכוונה שהוא חי ממש ופועל בלי רשות, אלא אני מניח שהוא מנסה לבדוק עדכונים מאחורי הקלעים או להעביר מידע, והתג מזהה אותו וקורס. המנטליות של מיקורסופט לאחרונה הוא לעשות הרבה דברים מאחורי הקלעים וגם לעדכן חלקים אוטמטית (כך הבנתי מהפומולמסים על וינדוס 10).
אם תנסה להפעיל את התג כשאר יש VS ברקע תקבל הודעה שלא משתמעת לשני פנים: debugger detedted.
התעוררתי לחשוב כן מכיון שב2010 לא היה את הבעיה הזו, ורק מ2015 התחילו הענינים קצת להתרועע. פונטים מסוימים מתחילים לא להופיע על המסך, וכן קריסות פתאומיות.
פורסם במקור בפורום CODE613 ב10/11/2016 19:49 (+02:00)
את זה כבר הבנתי מזמן, שלעשות עימוד בתוכנת תג ושיהא ויזואל סטדיו ברקע, אי אפשר.
עד לאחרונה עבדתי עם2010, הבעיה שבVS2015, מידי פעם הוא "מתעורר" לחיים, כנראה לבדוק עדכונים, והתג מזהה אותו, ונסגר אוטמטית.
כנראה שאת זה אפשר גם לסדר איכשהוא.
האם לבעלי נסיון בשניהם גם היה כזה דבר שהיה תקלות מהחפיפה של שניהם במחשב אחד? כי כרגע יש לי כמה באגים בתג שליבי תולה את זה בשידוך הזה.
פורסם במקור בפורום CODE613 ב10/11/2016 19:17 (+02:00)
הוא עדיין כותב לי את השגיאה שהוא לא יכול לטפל בפקדים שלא נוצרו באותו טרייד, אז הבנתי שאני צריך ל"הוציא" החוצה מהוורקר את מה שאני רוצה להתשמש בו בפקדים. ההתקדמות יכולה להראות גם אחוזים אבל אפשר גם להעביר אוביקט. וכרגע הקוד נראה כך:
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
int sum = 0;
for (int i = 1; i < 101; i++)
{
sum += i;
backgroundWorker1.ReportProgress(i, sum.ToString());
_suspendEvent.WaitOne(Timeout.Infinite);
Thread.Sleep(100);
}
}
private void backgroundWorker1_ProgressChanged(object sender, ProgressChangedEventArgs e)
{
progressBar1.Value = e.ProgressPercentage;
label1.Text = (string)(e.UserState);
}
פורסם במקור בפורום CODE613 ב09/11/2016 23:42 (+02:00)
נניח שאני עושה לולאה, ואני רוצה להספיק באמצע. אבל להמשיך אחרי קבלת ארוע מהתשמש אבל בדיוק באתו מקום.
אני עובד עם backgroundWorker, ויש לו אפשרות ביטול אבל לא Resume
הקוד כרגע נראה כך:
private void backgroundWorker1_DoWork(object sender, DoWorkEventArgs e)
{
int sum = 0;
for (int i = 1; i < 101; i++)
{
sum += i;
//כאן שיהא איזה אפשרות לעצור להמשיך מחדש
backgroundWorker1.ReportProgress(i);
}
label1.Text = sum.ToString();
}
פורסם במקור בפורום CODE613 ב09/11/2016 12:56 (+02:00)
מה ההבדל בין שניהם?
בוינפורמס, בתבת טקסט מרובה שורות כדי לרדת שורה צריך לכתוב את שניהם.
במסג בוקס כדי לרדת שורה מספיק אחד.
בוורד (כלומר שנגשים לוורד בצורה תכנותית) שניהם עושים סימן סוף פסקה אלא שאחד עבה ואחד דק.
באינדיזיין (שנגשים צורה תכנויתית) \r הוא מעבר שורה והשני סוף פסקה אמיתי.
מה הלוגיקה מאחורי זה, והאם יש שני סוגי סוף פסקה מאיזה טעם?
פורסם במקור בפורום CODE613 ב16/09/2016 12:25 (+03:00)
אני לא יודע אם זה טוב מה שעשיתי, אבל העתקתי את הקובץ הזה regtlibv12.exe לתקיה בוינינדוס 10 ומשם הפעלתי אותו לרסטרי של הקובץ TLB.
הוא הגיב מצוין.
הענין הוא שregsam לא עובד על TLB, לא ב10 ולא ב7, מה שכן ראיתי שאמור ללכת איתו זה TLBIMP.EXE.
והפעלתי את זה דרך שם והוא באמת הוציא אחריו איזה DLL אבל הוא היה קטן ומצומק ולא היו בכלל את כל הפונקציות שיש בDLL CT דרך רפרנס עם COM. לכן העדפתי לעשות בדרך זו.
פורסם במקור בפורום CODE613 ב26/08/2016 13:21 (+03:00)
מדובר בDLL של אינדיזיין.
אני לא יודע איזה שפה הוא נכתב [אני מעריך C++]. ואני אישית יכול להתשמש בו בויזואל סטדיו- באופן מוחלט ונהדר. אני כותב בC#.
הבעיה היא אצל הלקוחות, ששם זה לא עבר רגסטרי ולכן כנראה אין אפשרות לפנות לDLL הזה.
הבעיה לכשעצמה הוזכרה כבר כאן : אך הפתרון המוצע שם, וכן מה שכתב לי דוד ל.ט. בזמנו כאן לא פועלים בגרסאות מתקדמות של וינדוס.
הקוד להפעלה ראשונית, בהשראתו של דוד ל.ט., כאמור, הוא:
var MoreTblFiles = Directory.EnumerateFiles(@"C:\ProgramData\Adobe", "*.tlb", SearchOption.AllDirectories);
foreach (string currentFile in MoreTblFiles)
{
p.StartInfo.Arguments = "\"" + currentFile + "\"";
p.StartInfo.FileName = System.Runtime.InteropServices.RuntimeEnvironment.GetRuntimeDirectory() + "regtlibv12.exe";
counter++;
if (!p.Start())
{
MessageBox.Show("היתה בעיה.");
}
p.Close();
שזה מחפש את קבצי הTLB באשר הם בספריות אליהם הוא מפנה, ולאחר מכן עושה להם רגסטרי.
אני אישית הייתי מעדיף פתרון כזה שאני יביא איתי את הDLL למחשב הלקוח, ושם יעשה לו רגסטרי כראוי, כך שלא יהיה תלות במה שיש או אין לו במחשב.
פורסם במקור בפורום CODE613 ב25/08/2016 10:24 (+03:00)