Codejock .NET?

Are there any plans to develop a .NET version of XtremeSuite?

Any new development on this subject?

Whats the benefit of .net control above a activex control?

So the poll is locked for you guys?  Yes, .NET is definetly on the way, you can probly expect the first .NET component by the end of the year, which will be the TaskPanel.  The other controls have no ETA at this time. 

https://forum.codejock.com/forum_posts.asp?TID=5411&FID=18&PR=3

The poll is mainly trying to find out which environment is most widely used by Codejock customers.  VS 2002 seems to be a little picky when developing the Design Time interface and extra effort is needed to make it compatible with all three versions of .NET.

Hope this helps

After experiencing several show-stopping issues with skinning in 11.1 COM, I'd really really really like to see native .NET skinning ability included in Codejock's first .NET offering.

The TaskPanel is old news

Cheers ~ jp

They have not been submitted, but rather vented here:
https://forum.codejock.com/forum_posts.asp?TID=6905

Both issues seem related and deal with the skin appearing to be tacked on, rather than fully replacing the system-created window.

SkinMDISample:
When child windows first appear, they are not skinned.

All SkinFramework samples:
When closing the main form, it first loses the skin before closing.

Granted - the unskinned forms are displayed for fractions of a second, but that's fractions of a second longer than can be shipped in a professional-grade product.

Regards ~ jp

apuhjee wrote: All SkinFramework samples: When closing the main form, it first loses the skin before closing. Granted - the unskinned forms are displayed for fractions of a second, but that's fractions of a second longer than can be shipped in a professional-grade product.

This only applies to the form that actually hosts the SkinFramework component and this is because the AxHost for the OCX is in the forms Components collection and gets disposed before the form. Simply remove it from the components collection on top of the forms Dispose method and dispose it manually on the end and the flicker is gone.

harald

apuhjee wrote: Thanks so much Harald. That did, in fact, work.

The cleanest solution for the above problem would be to add the SkinFramework instance to a form that will never be shown, e.g.

skinFramework.BeginInit();
new Form().Controls.Add(skinFramework);
skinFramework.EndInit();

This way you won't see any flicker without having to modify the Dispose method.

apuhjee wrote: Would you also have a solution for when forms are first being created? In SkinMDISample, forms first appear unskinned for a brief moment.

After moving the ApplyWindow() call from OnVisibleChanged() to OnLoad() I also don't see any flicker for this case.

apuhjee wrote: This leads me to a broader question - one that has always bothered me with .NET forms. Is there a way to ensure that a form is fully created with all initialization performed before displaying it on the screen?? It always seems to me that forms are drawing themselves component-by-component when they are first displayed.

Ever tried to set the DoubleBuffered property to true?

good luck,
harald

Sorry to go back to the original topic of this (old) thread, but I really hope Codejock comes out with some managed code soon, preferably in .NET 2.0. I hate to say it, but if I were to find a company that offered a fully managed solution in .NET 2.0, I would switch. Marshaling back and forth with COM interop is for the birds. Times are changing, gotta keep up to make money. I have subscribed to codejock for three or four years, and I would like to stay, but managed code is very important to me and my work, now.

I don't think that it makes sense to rewrite the Toolkit for WinForms. The current Toolkit serves the MFC, VB6 and WinForms market pretty well. WinForms is also HWND based so there is no disadvantage.

Also while I agree that the VB6 usage is dwindling there is still a huge customer base. Many also continue to use MFC over WinForms for various reasons. The MFC controls from Codejock perform way better than anything else on the market, which is also the reason why I personally don't use WinForms at all.

I guess there is a market for MFC controls for at least the next 3 or 5 years.

WPF is a whole different story and I hope that Codejock will serve this market in the future too.

SuperMario wrote: Actually TaskPanel and ShortcutBar will be coming out very soon and all other components are currently in development.

Are they written in C# or C++/CLI? For WinForms or WPF?

Krenshau wrote: I don't think WPF will run on XP, will it?

It does, .NET 3.0 can be installed on XP, Server 2003 and Vista (pre-installed).

A WinForms toolkit wouldn't make sense in my eyes, WinForms was nothing more than a managed wrapper around the common controls and HWND based controls.

WPF does have some advantages. A DirectX based toolkit which integrates well with WPF  might be cool.