Сейчас в дистрибутивах используются 2 версии .NET – v4.0 для Windows XP/Vista и v4.7.1 для всего остального под Windows. При этом XP и Vista совместимы с .NET 4.6, а .NET 4.8 поддерживает Win 7 и выше. Есть какие-то объективные причины не включать в дистры более актуальные версии .NET или просто никто не обращал внимание?
Это давняя история. Помнится, XP не поддерживала 4.5 в ранних версиях. 4.5 отличается от 4.0 очень мало.
4.8 тоже мало отличается от 4.7.1. Это можно поменять. Но при замене у массы пользователей могут быть проблемы. Ввиду незначительности этого мы это не делаем.
Следующая остановка - Net Core, но там проблемы с генерацией кода по вине Microsoft.
Исправили - используем .TryGetValue
Решили проблему с exit, оттестировали - проверяйте
Можно создать отдельную экспериментальную ветку для таких целей (dev ?), пускай тестируют, кому нужно/интересно. Вообще было бы полезно и для проверки других неоднозначных или потенциально рискованных/не до конца протестированных изменений публиковать отдельно эспериментальные бинарники – можно легко делать их автоматом через GitHub Actions и пускай висят там временно в виде скрытых “артефактов”, а не на офиц. сайте. Тогда скачать их смогут только зарегистрированные на гитхабе энтузиасты и читатели форума. Только желательно еще как-то явно пометить такие сборки, чтобы не путать их в работе и багрепортах с офиц. релизами – отображать дату/последний коммит в заголовке главного окна, например: PascalABC.NET 3.8.1-dev-20210109@1315-8fd4732
. С таким подробным тэгом будет легко ориентироваться в репе и повторить билд, если нужно.
Так c версии .NET 6, которая ожидается где-то в конце года, Net Core, .NET Desktop, SDK и ASP.NET сливаются же в единый модульный фреймворк, который будет поддерживать почти все, начиная с Win7 и выше, Android 5.0+, iOS, Linux и MacOS. Даже какой-то универсальный гуй MAUI пилят к нему, но пока экспериментальный.
А эти проблемы с генерацией кода носят фундаментальный и неразрешимый характер или только временный? И почему эти проблемы не мешают сейчас родным майкрософтовским компиляторам C#, Visual Basic и F# – там принципиально другой подход к генерации кода?
Пока не будет AssemblyBuilderAccess.Save, этот новый недо-NET не нужен. Это называется гора родила мышь.
.NET Multi-platform App UI (.NET MAUI) is a cross-platform framework for creating native mobile and desktop apps with C# and XAML. Using .NET MAUI, you can develop apps that can run on Android, iOS, iPadOS, macOS, and Windows from a single shared code-base.
Какой же он кроссплатформенный, если нет поддержки линукса
То есть опять, миграция со старого доброго Windows Forms просто бессмысленна. Потому что гуйка кроссплатформенного как не было, так и нет
Проблема одна - у AssemblyBuilder невозможно под NET Core сохранить сборку на диск.
В Рослине эта проблема решается своим движком, в котором все классы, генерирующие IL-код как будто специально закрыты. То есть, получается, что Microsoft специально хочет избавиться от разработчиков сторонних компиляторов на NET Core
А как это можно сделать надежно и универсально, если там до сих пор целый зоопарк конкурирующих и несовместимых графических серверов, тулкитов, драйверов и окружений? Который только ширится и постоянно видоизменяется без какого-либо четкого плана/стратегии/стандартов, а некоторые вообще регулярно ломают совместимость сами с собой даже при минорных релизах во имя эфемерного рандомного “прогресса”. Под что им конкретно пилить там? И какой им резон тратить сейчас ресурсы и пытаться попасть в пеструю кучу хаотично двигающихся целей, которых на поляне Dektop’ов едва можно разглядеть даже в лупу? Сообщество линукса само виновато в своей маргинальности и непредсказуемости: лебедь раком щуку…
А как же сейчас работают все компиляторы RemObjects Elements (уже для 6 языков) с таргетами .Net Core и .Net 5.0?
Elements fully supports creating projects for all parts of the .NET Core ecosystem. .NET Core supports three different runtimes:
- Microsoft.NETCore.App
- Microsoft.ASPNETCore.App
- Microsoft.WindowsDesktop.App
The
Microsoft.WindowsDesktop.App
runtime is only available on Windows, and can be used to build GUI applications using WinForms and WPF. It is the closest analogue to the soon-to-be-deprecated classic .NET Framework 4.x.
The Echoes compiler back-end is used for projects that compile for the .NET Common Language Runtime (CLR). It emits Intermediate Language (CLR IL) byte code that is compatible with .NET, .NET Core Mono/Xamarin and other CLR implementations.
Правда, там есть еще такой нюанс:
Different than the classic .NET Framework, .NET Core application projects with an output type of
Excutable
orWinExe
do not compile to an.exe
file that contains IL code (and could be run directly on Windows). Instead, they compile to a.dll
that contains the IL code and a platform-specific CPU-native stub binary (.exe
on Windows, and extension-less on Mac and Linux) that can be run directly locally, whether you are building on Windows, Mac or Linux.
В Java это уже давно решено
Это хороший вопрос. Но код у них закрыт. Думаю, напилили свой генератор IL-кода. Просто это огромный кусок компилятора
Да это ради бога - знали б мы как это сделать легко…
Скажите честно, вы хоть раз гуи под Линукс писали или просто сообщаете свои ощущения как пользователя? Любой из нативных кросс-платформенных тулкитов (например, Gtk или Qt) нормально сработает на подавляющем большинстве дистрибутивов Линукса. Зачем фантазировать-то?
Из 3.8.2:
Операция not in
Операция
not in
является противоположной операцииin
:begin var a := Arr(1,3,5); if 4 not in a then Print('отсутствует'); end.
Это классно, можно тогда сразу и o is not type
?
Да, мы думали об этом. Сделаем - попозже
Читаю я ваши описания обновлений и понимаю, что в коде критически не хватает комментариев
Я так понимаю, что тут далее объявленные элементы неявно группируются в предыдущий или что-то в этом роде?
uses PlotWPF;
begin
var g := new GridWPF(2,2,10);
var c := new LineGraphWPF(0,Pi,v -> v*Sin(v*10));
c.PlotRect := Rect(0,0,10,10);
c.Graph[0].ChangeData(0,Pi,x->x*x);
c.Graph[0].Color := Colors.Green;
c.Graph[0].Thickness := 3;
c.AddLineGraph(0,Pi,v -> Sqrt(v));
var c2 := new LineGraphWPF(0,Pi,v -> Sin(v*10)-Cos(v*7));
var c4 := new MarkerGraphWPF(|1.0,2,3,4,5|,|5.0,15,7,12,2|);
c4.AddLineGraph(|1.0,2,3,4,5|,|5.0+1,15+1,7+1,12+1,2+1|);
c4.AddMarkerGraph(|1.0,2,3,4,5|,|5.0+1,15+1,7+1,12+1,2+1|,Colors.Bisque,MarkerType.Diamond,8);
c4.Graph[0].Thickness := 0.7;
c4.Graph[1].MarkerType := MarkerType.Box;
c4.Graph[2].Thickness := 0.7;
var gg := new GridWPF(2,2,3);
new LineGraphWPF(0,2,x->Cos(10*x));
new LineGraphWPF(0,2,x->Sqrt(x));
new LineGraphWPF(0,2,x->Sin(10*x));
new LineGraphWPF(0,2,x->exp(x));
end.
Да, Grid - группирующий элемент, и при его создании он становится активной панелью.
Чтобы переключить - SetActivePanel
Как-то неочевидно :\