- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
#region копирование в буфер
private void copia_Click(object sender, EventArgs e)
{
StringBuilder sb = new StringBuilder();
for (int i = 0; i < listBox1.Items.Count; i++)
{
sb.Append(listBox1.Items[i].ToString());//Добавляем строчку из листБокса
sb.Append((char)13);//Перенос строки
sb.Append((char)10);//Перевод каретки
}
Clipboard.SetText(sb.ToString());//Отправляем всё в КлипБорд
}
#endregion
#region Сохранить в файл
private void save_Click(object sender, EventArgs e)
{
saveFileDialog1.DefaultExt = ".txt";
saveFileDialog1.OverwritePrompt = true;
saveFileDialog1.Title = "Координаты";
saveFileDialog1.Filter = "Text Files|*.txt";
if (saveFileDialog1.ShowDialog() == DialogResult.OK)
{
StreamWriter sw = new StreamWriter(saveFileDialog1.FileName);
StringBuilder sb = new StringBuilder();
for (int i = 0; i < listBox1.Items.Count; i++)
{
sb.Append(listBox1.Items[i].ToString());//Добавляем строчку из листБокса
sb.Append((char)13);//Перенос строки
sb.Append((char)10);//Перевод каретки
}
sw.WriteLine(sb);
sw.Flush();
sw.Close();
}
}
#endregion
Follow us!
Хоть не понос.
пишем
Сохранение в файл:
Так?
Лучше всё-таки юзать foreach, он проверяет collection._version и в случае чего сразу выкинеть InvalidOperationException, .
Используя foreach вы создадите еду для габидж колектора (класс энумератора). При теоретическом изменении коллекции процесс прекратится екзепшном.
Используя цикл фор вы создадите одну лишнюю 4х байтную переменную. И при теоретическом изменении коллекции процесс пройдет нормально (Count вернет точное количество элементов в массиве)
Ололо, энумератор - структура, хранится в стеке. ВНЕЗАПНО: public struct Enumerator : IEnumerator, IDisposable, IEnumerator<T>
> И при теоретическом изменении коллекции процесс пройдет нормально (Count вернет точное количество элементов в массиве)
Да ну? Поток #1 получил значение collection.Count, сравнил с i, условие верно => вошёл в блок цикла. В это же время другой поток удалил/добавил один объект. Первый поток, УЖЕ будучи в итерации, до сих пор считает, что объектов 4, а не 3 или 5. В итоге непонятные баги и прочее (итерация продолжается дальше потому что). А с foreach сразу ясно, что ошибка в синхронизации (хотя непонятные баги тоже могут вылезти, но вероятность меньше).
с вами согласен, в яве (от шарпа я убег едва познакомившись) именно так.
почему?
2. слишком длинные имена.
3. вообще дотнет значит мелкософт и виндоуз, а это секта. То бишь если повязать себя с ним, то заставят и другие мелкософт-решения юзать. Даешь свободу в опенсорсе и кроссплатформенности!
4. многое слизано с той же явы, но по-своему и не всегда удачно
ну и еще 100 ньюансов (лень перечислять), из за которых я сказал дотнету:"изыди!"
не хочу будоражить холивареров, но ЛИЧНО мне ява приятнее со всеми ее недостатками
2. В смысле?
3. Ну это фигня, моно давно вышла в продакшн-режим, от МС не зависит.
4. Если взглянуть со стороны, то то, что "слизано с явы", было придумано ещё лет за 20 до явы. Чего только ява не слизала...
> ну и еще 100 ньюансов
Ну эти нюансы все какие-то несерьёзные.
Вот я выбрал моно потому что:
1) можно собрать в натив в один экзешник
2) простой доступ к C api.
3) скорость за счёт классов в стеке, т.е. структур
4) большая продуктивность засчёт компонентно-ориентированности (евенты, свойства, и т. д.)
(мне эти четыре пункта важнее нейминг конвеншонз)
Кросплатформ вообще хрень в том числе и у явы. Порой легче написать что-то кросплатформенное на си, чем пытаться собрать в кучу яву, JNI, HERNI и прочий шлаг вместе под каждую платформу.
2. ну, из головы пример: modify() короче и приятнее чем AddSingleNameModifier()
3. моно еще не так полон, как дотнет
4. хотя бы ява сделала это более-менее удобно. Или мне так показалось - с первого взгляда, и кажется до сих пор
Насчет потому что: меня заинтересовал D, в качестве "продвинутого" нативного С, но не столь сложного, как С++
ничо не нравится. и как же жить теперь?
> А ClassA.ClassB - это внутренний класс или статическая переменная?
Ну вам прямо не угодишь. Сделал майкрософт венгерскую нотацию - жаловались. Убрали все вспомогательные префиксы - опять жалуются. Одни жалуются на I в IDisposable. Другие жалуются, что нет A у абстрактных классов. КАКИХ ИХ РАЗЛИЧАТЬ??!!!
> А ClassA.ClassB - это внутренний класс
В сишарпе внутренние классы редко используются, не существенно.
> А ClassA.ClassB - это внутренний класс или статическая переменная?
Если сидеть с интеллисенсом, то таких проблем совсем нет. Я даже не помню ни разу, чтобы вот сидел и думал: это свойство или статическая переменная или класс?.. Сразу как-то всё понятно. (там для особо вдумчивых картинки для каждого типа сделали, сразу видно, что где)
> 3. моно еще не так полон, как дотнет
Да ну? clr2.0 реализован весь за исключением пары редко исопльзуемых методов и классов. А больше и не надо.
Аналогию не понял. "Кот васька" это скорее объявление переменной "васька" класса "Кот". Вот это почему-то в обоих языках вас не смущает :) По такой аналогии (с естественными языками) классы должны писаться с маленькой буквы, а instances - с большой. (Напр., как в русском языке: "президент" как класс и "Президент" как какой-то конкретный президент.)
Да и лично на мой вкус выглядит солиднее, идентификаторы с маленькой буквы ассоциируются с локальными переменными . Почему имена публичных методов, интерфейсов, "идущих в свет", должны прибедняться и идти с маленькой буквы? :)
скромность - сестра таланта ))
Если же количество элементов увеличилось то цикл пройдет без екзепшна (Что мне тоже кажется логичным)
Сами посмотрите
System.Windows.Forms.ListBox.ItemArray.E ntryEnumerator
private class EntryEnumerator : IEnumerator
для этого случая это не так важно, что выделяется память, проход по коллекции контрола по идее не должен совершаться очень часто (в отличие от, например, прохода по коллекции спрайтов, чтобы отрисовать 2д).