ГЛ
Получается запутанно
Size: a a a
2020 March 23
S
можно хоть кусочек метода в другом потоке обработать, так именно async работает. Ничго в этом страшного нет
ГЛ
Я именно хочу код разнести, чтобы это всё не было в одном месте
S
Я именно хочу код разнести, чтобы это всё не было в одном месте
разноси) какая разница в каком потоке оно обрабатываться будет? Классы и потоки не взаимосвязанны
ГЛ
Так а метод, которые будет приниматься делегатом, как мне вынести в другой класс?
S
Так а метод, которые будет приниматься делегатом, как мне вынести в другой класс?
class A
{
void INeedSecondThread()
{
var b = new B();
var t = new Thread(b.DoSomething);
}
}
class B
{
public void DoSomething()
{
//Do Work
}
}
{
void INeedSecondThread()
{
var b = new B();
var t = new Thread(b.DoSomething);
}
}
class B
{
public void DoSomething()
{
//Do Work
}
}
ГЛ
class A
{
void INeedSecondThread()
{
var b = new B();
var t = new Thread(b.DoSomething);
}
}
class B
{
public void DoSomething()
{
//Do Work
}
}
{
void INeedSecondThread()
{
var b = new B();
var t = new Thread(b.DoSomething);
}
}
class B
{
public void DoSomething()
{
//Do Work
}
}
Я тебя очень благодарю. Именно это я и хотел. Просто не знал, что так можно 😃
S
Я тебя очень благодарю. Именно это я и хотел. Просто не знал, что так можно 😃
ну именно это нормально. Просто насколько оправдано такое разделение одного класса на 2 это уже смотреть нужно
S
А потоки на то и потоки, чтобы кусок кода выполнять где-то в контексте вторичного потока, а классы там не причем
ГЛ
Ну это уже отдельная история😁Просто получается так, что этот поток всё жизнь программы будет существовать
Ч
class A
{
void INeedSecondThread()
{
var b = new B();
var t = new Thread(b.DoSomething);
}
}
class B
{
public void DoSomething()
{
//Do Work
}
}
{
void INeedSecondThread()
{
var b = new B();
var t = new Thread(b.DoSomething);
}
}
class B
{
public void DoSomething()
{
//Do Work
}
}
лучше статик объявить, чтобы не создавать объект
S
лучше статик объявить, чтобы не создавать объект
спорно) в кокретно с классами A и В может и лучше, а если классы сложнее, то сильная связанность получается, что плохо
АМ
Доброго дня. Wpf mvvm. ObservsbleCollection. Можно ли как то на время обновления коллекции в другом потоке отключить обновление интерфейса? Пару тысяч элементов в отдельной таске меняю visibility и весь интерфейс виснет
PE
Андрей Мацко
Доброго дня. Wpf mvvm. ObservsbleCollection. Можно ли как то на время обновления коллекции в другом потоке отключить обновление интерфейса? Пару тысяч элементов в отдельной таске меняю visibility и весь интерфейс виснет
Может тогда имеет смысл отделную коллецкию для обновления зависти, а уже потом присвоить изменения в интерфейсе?
АМ
Если отдельная коллекция, то слетают все биндинги. Сейчас в цикле обхода прикрутил task.delay(10).wait(). Но время обхода значительно увеличилось. А элементов под 16к. В общем ощутимо (
PE
Андрей Мацко
Если отдельная коллекция, то слетают все биндинги. Сейчас в цикле обхода прикрутил task.delay(10).wait(). Но время обхода значительно увеличилось. А элементов под 16к. В общем ощутимо (
И ты прямо 16К элементов отображаешь в интерфейсе одновременно?
PE
Ты уверен что ты все делаешь правильно?
АМ
Конечно не уверен)) в элементе включена виртуализация, на данном этапе это помогает от диких лагов)
PE
А что ты такое отображаешь, если не секрет? Просто сложно представить задачу, в которой столько элементов в интерфейсе вообще помещаются))