Print Page | Close Window

Codejock .NET?

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: General Discussion
Forum Description: Topics Related to Active-X COM Development in General
URL: http://forum.codejock.com/forum_posts.asp?TID=4667
Printed Date: 29 April 2024 at 4:20am
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com


Topic: Codejock .NET?
Posted By: Daley
Subject: Codejock .NET?
Date Posted: 27 July 2006 at 3:30am
Are there any plans to develop a .NET version of XtremeSuite?
Many .NET developers would prefer to avoid ActiveX/COM Interop in favour of 'managed code'.
 


-------------
Regards,

Daley



Replies:
Posted By: WaaZ
Date Posted: 27 July 2006 at 2:47pm
I have been told by the team that this is on the way but may take some time, but its definitly on the cards.


Posted By: einar@notus.no
Date Posted: 20 September 2006 at 12:55am
Any new development on this subject?


Posted By: Flex
Date Posted: 30 October 2006 at 11:26am
Originally posted by einar@notus.no einar@notus.no wrote:

Any new development on this subject?


Bump.

Would love to see .net versions of your controls.

The competition out there is pretty slim for managed code and what is available tends to be bloated and un-intuitive.


Posted By: Shragel
Date Posted: 30 October 2006 at 7:11pm
Whats the benefit of .net control above a activex control?


Posted By: Krenshau
Date Posted: 02 November 2006 at 2:09pm
I would love to see .net controls as well, especially .net skinframework. I have created CCWs just so I can use the VB6 interface with skins, and still access the .net 2.0 framework. I know skinning is possible with .net, but it isn't as easy as adding three lines of code in VB 6.
 
I am looking forward to voting in the poll, but it seems to be locked. I use visual studio 2005, and think .net control in .net 2.0 would be ideal. The .net 1.0 and 1.1 are fading away (although still in use) and making way for .net 2.0. The .net 3.0 framework probably won't be big for a while because I haven't seen anything about it being supported back to Windows 98, or 2000 for that matter.
 
Anyway, that is my .02 cents.


Posted By: SuperMario
Date Posted: 02 November 2006 at 3:04pm
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


Posted By: SuperMario
Date Posted: 02 November 2006 at 3:12pm
Try to vote now


Posted By: apuhjee
Date Posted: 20 April 2007 at 12:42pm
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

-------------
I like mathematics because it is not human and has nothing particular
to do with this planet or with the whole accidental universe — because,
like Spinoza's God, it won't love us in return.


Posted By: SuperMario
Date Posted: 20 April 2007 at 1:13pm
Originally posted by apuhjee apuhjee wrote:

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


Which are?  And you sent them to support to be fixed?


Posted By: apuhjee
Date Posted: 20 April 2007 at 5:08pm
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


Posted By: apuhjee
Date Posted: 20 April 2007 at 5:36pm
A little unrelated... but is this font color for a highlighted TaskPanelGroupItem correct?



Posted By: haraldradi
Date Posted: 26 April 2007 at 2:49am
Originally posted by apuhjee 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


Posted By: apuhjee
Date Posted: 26 April 2007 at 11:41am
Thanks so much Harald. That did, in fact, work.

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

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.

Regards ~ jp


Posted By: haraldradi
Date Posted: 26 April 2007 at 6:56pm
Originally posted by apuhjee 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.

Originally posted by apuhjee 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.

Originally posted by apuhjee 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


Posted By: apuhjee
Date Posted: 27 April 2007 at 11:04am
Originally posted by haraldradi haraldradi wrote:

After moving the ApplyWindow() call from OnVisibleChanged() to OnLoad() I also don't see any flicker for this case.
 
As I suspected, this not only did this not fix the problem - it made it worse by not skinning the mdi child forms at all.  It would be odd for either Mike or Oleg to put this code in such a strange place for no reason.  I also suspect that this had a lot to do with why they originally didn't think it was possible for the skin framework to work with .NET period.
 
Purhaps you could post some example code that you have working?
 
Originally posted by haraldradi haraldradi wrote:

Ever tried to set the DoubleBuffered property to true
 
I've attached an example of what I'm talking about. When you launch this app, you can literally see the buttons paint one at a time (though very quickly).  Double buffering on the form makes no difference.  I'm looking for some sort of event or indicator letting me know what a form is completely initialized and ready to be drawn to the screen.  Something that would allow the following:
 
1) create new form()
2) set visible = false
3) show form
4) receive notification that form is fully initialized
5) set visible = true
 
Cheers ~ Jason
 
http://forum.codejock.com/uploads/20070427_110307_ButtonForm.rar - uploads/20070427_110307_ButtonForm.rar


-------------
I like mathematics because it is not human and has nothing particular
to do with this planet or with the whole accidental universe — because,
like Spinoza's God, it won't love us in return.


Posted By: Krenshau
Date Posted: 09 May 2007 at 12:26am
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.

-------------
Ben
QAS Information Systems


Posted By: apuhjee
Date Posted: 18 May 2007 at 1:11pm
Ben -
I'm fearing that this is a hopeless dream.  Codejock's programmer(s) is/are solidly rooted in Win32/MFC.  Codejock, as a company, caters to and is probably kept alive by the dwindling VB6 crowd.  Tutorials, Samples, and Documentation focus on VB6.  The C# samples are auto-generated by a tool called Instant C#... resulting in a 7.0 sample that must be auto-converted yet again by Visual Studio 2005 in order to bring things into the year 2007.  The auto-generated code is crap - RibbonSample actually has a property being called as if it were a function!!  Frustration is an understatement.
 
We've evaluated DotNetBar and NetAdvantage.  Maybe it's just that we've gotten used to the simple Codejock API... but these other suites are plain obtuse.
 
Finally - there's a performance issue.  Even with all of the interop, the visual components written in native c++/mfc seem to perform much better than visual components written in the .NET framework... Maybe Codejock can step up and raise the bar, though. 
 
We've been with this suite for the past couple of years, but like you mention - the first product with Codejock's features, quality, and support that is made BY .NET PROGRAMMERS / FOR .NET PROGRAMMERS will have our cash.  And it will be a shame if that company is not Codejock itself.
 
Regards ~ jp


Posted By: ABuenger
Date Posted: 18 May 2007 at 3:44pm
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.



-------------
Codejock support


Posted By: SuperMario
Date Posted: 21 May 2007 at 9:57am
Originally posted by apuhjee apuhjee wrote:

Ben -
I'm fearing that this is a hopeless dream.  Codejock's programmer(s) is/are solidly rooted in Win32/MFC.  Codejock, as a company, caters to and is probably kept alive by the dwindling VB6 crowd.  Tutorials, Samples, and Documentation focus on VB6.  The C# samples are auto-generated by a tool called Instant C#... resulting in a 7.0 sample that must be auto-converted yet again by Visual Studio 2005 in order to bring things into the year 2007.  The auto-generated code is crap - RibbonSample actually has a property being called as if it were a function!!  Frustration is an understatement.
 
We've evaluated DotNetBar and NetAdvantage.  Maybe it's just that we've gotten used to the simple Codejock API... but these other suites are plain obtuse.
 
Finally - there's a performance issue.  Even with all of the interop, the visual components written in native c++/mfc seem to perform much better than visual components written in the .NET framework... Maybe Codejock can step up and raise the bar, though. 
 
We've been with this suite for the past couple of years, but like you mention - the first product with Codejock's features, quality, and support that is made BY .NET PROGRAMMERS / FOR .NET PROGRAMMERS will have our cash.  And it will be a shame if that company is not Codejock itself.
 
Regards ~ jp


It is not a helpless dream.  Actually TaskPanel and ShortcutBar will be coming out very soon and all other components are currently in development.

For .NET samples, one sample is created from scratch in VS2002 in C# or VB.NET.  Then to save time that one sample is converted to the other language.  They must be created in VS2002 so that all users can open them.


Posted By: ABuenger
Date Posted: 21 May 2007 at 11:50am
Originally posted by SuperMario 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?



-------------
Codejock support


Posted By: Krenshau
Date Posted: 06 June 2007 at 3:35pm

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



-------------
Ben
QAS Information Systems


Posted By: ABuenger
Date Posted: 06 June 2007 at 6:49pm
Originally posted by Krenshau 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.



-------------
Codejock support



Print Page | Close Window

Forum Software by Web Wiz Forums® version 12.04 - http://www.webwizforums.com
Copyright ©2001-2021 Web Wiz Ltd. - https://www.webwiz.net