Open Tape-Worm opened 3 years ago
Check with #178
FYI, this problem is getting very difficult to manage.
The workaround provided only works for simple projects. Anything remotely complex (e.g. with custom controls embedded into the form) starts becoming difficult, at best, and impossible at worst, to manage.
Since I'm writing an API that allows users to write their own plug ins for this application this issue, makes it so others can't use my stuff without implementing a rather annoying hack to make it work which can require some intimate knowledge of how all this stuff works under the hood.
Has there been any progress on getting this issue fixed? Would you like me to do some testing for you guys on this?
Has there been any progress on getting this issue fixed?
It is really annoying - I agree. I'm still battling with this, and it seems that it has got worse now that VS16.11 has released, as NO controls show up ! As linked- check the progress against #178 and the others linked to it..
implementing a rather annoying hack to make it work
Can you elaborate on your workaround ?
It's just the standard workaround where you make the project target multiple frameworks, one for 4.8 and the other for 5.0. The other workaround where you link to a control/form in a separate .NET 4.8 project is even worse as soon as you add a single custom control and/or embedded resources.
Within my project, the first workaround works fine, but when I try to use it outside of my project source code that's when it all breaks down. Because I do not ship out the 4.8 code, users cannot link against my APIs and they cannot access the ribbon and create their own ribbon interface using .net 5 - which is something that I really want to expose.
I also tried a code-first approach where I started to create a ribbon builder, and that looked promising until I found that I could not access the controls by name via the control hierarchy in the ribbon.
As for why I don't ship out the 4.8 projects: I have a lot of C# 9 code, and there's parts (e.g. major parts of the Record type) that just don't work in 4.8 regardless of langversion. I #ifdef those lines of code out, thus making the .NET 4.8 code unusable (but can still compile).
If I had the ability to turn off the 4.8 framework, and the ribbon allowed me to set it up in the .NET 5 designer, then all of this would no longer be an issue.
Thanks for the report.. I'll keep pushing to try to fix each time I do a PR.
Thank you
So following the "Manual" method of adding via the properties, and then adding into each collection (Rather than clicking in the design area and performing add).
It (Canary V2108.1) eventually spits out this:
But the Attached Debugger to visual studio didn;t even blink, so this is a reflection mess !
Yep, that's what I've been getting. I could be wrong, but that designer looks like it's a standard .NET designer? That could be why you're not seeing anything in the debugger?
Sorry for the sidebar question. I'm preparing to upgrade a large net48 project to NET5. I'm hesitating since it uses krypton controls extensively throughout the application. I've been digging through the open issues to try and piece together any issues I might expect, but it's hard to determine what's remaining. Other than the issue presented above, is the next stable build of krypton expected to have any remaining NET5 designer or runtime bugs? I'm fine with targeting multiple frameworks if necessary. Or would it be safer to wait until next year? Thanks
This is still a problem in <PackageReference Include="Krypton.Toolkit.Nightly" Version="6.2110.296-alpha" />
in Visual studio 16.11.4
Ribbon Controls demo - nuget
.Net5 only (Edit csproj, close and re-open visual studio to ensure any dll is "Flushed")
Document outline looks like this and the tab control does not respond to click events in designer
Redo but only have .net48 in csproj:
Loads more controls:
and designer is clickable:
@sdreb3421 1) is the next stable build of krypton expected to have any remaining NET5 designer or runtime bugs? 2) I'm fine with targeting multiple frameworks if necessary. 3) Or would it be safer to wait until next year? Thanks
1) looks like it might 2) that is the safest way forward for the designer work, and then just push / install from the .net5 build bin directory 3) It is only the designer code when loaded into Visual Studio that is causing a problem. The actual runtime code is the sme as is fine.
@Smurf-IV thanks for the update. I just figured out that one of my libraries (OpenTK) does not play nice between framework and core, so I can't target multiple frameworks.
If it's only the ribbon that has issues I could just handle UI changes programmatically. Do you know of any other designer issues with net5 krypton controls?
FYI
If you need to target different targets then the csproj can do that for you via Choose
and When
clauses, or just plain name matching.
In Visual Studio 17P7 it's even worse with just .net5 :
But the Collection editors (Sort of like designers) can be accessed via the Collection properties:
Also the Toolbox does not list "Any" Krypton components! (And they do not in 16.11.4 either!)
Just checking in on this to see if there's been any progress on fixing the designer issue? Will you need the new Windows Forms SDK to make this work?
Hi @Tape-Worm
A discussion has been posted here https://github.com/Krypton-Suite/Standard-Toolkit/discussions/684
Hi @Tape-Worm
Yes the new Windows Forms SDK will be needed to fix this, since Microsoft broke something in-between 4.8 and .NET Core. One solution that may work is to add 'net48' to your 'TargetFrameworks'. This will force the designer to use a previous version.
I know this started with ".net5 ...." But ".NET 5.0 will reach End of Support on May 08, 2022" So I have changed the title to .Net6 to keep it relevant (And I'm still checking any solution !!)
Hi. Any updates on this issue? I'm experiencing the same error, ...because it is an abstract class, when trying to add an item to a ribbon group. I'm using VS 2022, .NET 6 and v65.22.6.152 of the Krypton.Ribbon package. I'm not able to use the suggested workaround with multiple target frameworks or just net48 due to some 3rd part components i have to use...
Not really, everyone is waiting for this.
https://github.com/Krypton-Suite/Standard-Toolkit/discussions/684
Hi @jfriborg
Can't really fix until the WinForms designer is properly fixed for .NET.
Have MS finally enabled Designers ?? https://devblogs.microsoft.com/dotnet/custom-controls-for-winforms-out-of-process-designer/
@Smurf-IV Does this need to be a new feature request to add/fix designers?
I think this was supposed to be left open waiting for the MS, then it would be fixed against this. There are other "bugs" in the backlog which also refer to designer issues, so they should all be taken into account.
I think this was supposed to be left open waiting for the MS, then it would be fixed against this. There are other "bugs" in the backlog which also refer to designer issues, so they should all be taken into account.
@Smurf-IV Great, if you come across any bug reports relating to this, please apply the 'designer' tag if not already applied
To summarize: (Tested in VS 17.7.4, and using the 80.23.8.233 canary build)
The following exception is being thrown when using the "Debug dev" or "Debug Nuget" solutions; When opened in VS 17.8.p2:
BUT If a new project is started And the ribbon added then the experience is as per https://github.com/Krypton-Suite/Standard-Toolkit/issues/262#issuecomment-955655525 for net48 projects as well ???
Hi @Tape-Worm, @Smurf-IV & @Wagnerp
What is the status of this ticket?
@giduac
It's been a long time since I last looked at this (probably 6 months to a year), but the last I checked it was still broken. From what I understood wagner and smurf were waiting on some sort of thing from Microsoft to aid in building custom components with designers (I know very little about it I'm afraid).
https://github.com/Krypton-Suite/Standard-Toolkit/issues/593
Describe the bug After adding a group to the tab in the ribbon, the next level of containers fail with an error about abstract classes.
To Reproduce
Expected behavior Should allow adding of a line group, or other container types.
Screenshots Screen shot available here: https://github.com/Krypton-Suite/Standard-Toolkit/issues/260#issuecomment-897755055