I have gained some ground, i think, I now know from certain debugging traces and reading a few places what the error pertains to, and the grid is bound to a datasource, and if i unbind the datasource right before i call showdialogue, then i do not get this error, but whenever later on i try to reattach the same datasource, i get an error which is the arithmeticexception error i stated previously. Anyone have any ideas...?

Hi Mike, thanks for the prompt reply, unfortunately, I am not the descision maker, if it were up to me, it would be updated regularly, also we had issues last time we updated from our version to this one (by your suggestion 2 years ago, when we updated from vs2003 to vs2005)
Now we have an issue which is that the grid does not normally do this in any other case, and that if you reload the same form (before GCC comes by) the form loads without a problem, and the error message seems to always mention the gridbaglayout)
If you think this might be related to a bug with the grid, is there any possibility that instead of getting a fix, i could know why the bug is being produced and maybe change the way i coded this(maybe not have any datasource binding before the call to showdialogue?), in order to bypass the need for updating dlls???
I am looking forward to hearing the possibilities for explaining this behavior as I know you guys work really hard to provide quality support, but in this case, we will not be able to update to the next version, and as for 2 years being not nearly enough to suggest there is no more support for a product (hence why xp is still supported today,10 years later) I hope you can find a way to help us with this issue. Thanks in advance

Hi,

I'd certainly be happy to try to find a workaround for you. But there's not much I can do without being able to see and debug the issue. As I said above, we would need a small sample project demonstrating the exception. Are you able to reproduce the exception reliably in a small sample? If so, just post it here and I will check it out.

Ok, Mike, here is what is happeneing, I went further with my testing environment, and found these points out. 1) I built a com(tlb) for my vb.net dll, and used vb6.0 to call it. I had no issues, as I believe that vb6 sees the registered dll/tlb from the registry. 2)We have a delphi application that is using the tlb, but was compiled on a machine that does not have infragistic, and then transplanted to the server running the apps and with infragistic installed. My question, is that (not being versed in delphi) Is it possible if the delphi application linked the tlb reference for my dll, it should not have any issues when it comes to using the infragistic...or does infragistic need to be referenced also within the delphi app calling the tlb...this might be the issue, although I am unfamiliar with how infragistic treats application calling their dlls without having any references to them. Also my boss is interested in getting the new version of infragistics, only if we can guarantee this will cure the situation...?

I'm afraid you lost me with all that stuff about Delphi and tlb's. I don't think our assemblies are any different than any other assemblies in this regard, so if other assemblies work, I can't see why ours would not. If this is a limitation, it probably has nothing to do with the assemblies themselves, it's probably a limitation of Delphi. You might want to ask someone as Oracle if they have had experience with third-party assemblies in situations like this.

As for determining if the latest version fixes the problem, the easiest thing for you to do would be to download a trial version and test it out. You could make a copy of your project, update the copy to the new version, and see what happens.

Thanks for your prompt reply Mike, I appreciate the time you are putting into this. I reviewed the sales section of your website for the winforms, and it states clr2.0 but only shows vs2008 & 2010 as being compatible... does that mean we lose the designer aspect for using this latest version, and if so, being compatible is not enough, we would need the version before this if that was the case? I already sent out an email contacting your sales dept for the issues pertaining to redistribution, and also get some costs for the latest version. Please keep this open, as I am not sure if this (upgrading) will fix our situation, and I would like to atleast have the same ticket if possible to continue towards fixing our issue. Thanks Mike...will look for you reply to the question here and also keep you posted with the trial version see if it fixes things a little, and also the purchase of the latest version.

landerson999 said:

1) Can you guaranty me that having the next version of infragistics will not leave us crippled seeing as we are using vs2005, and would not like to hear that we need to upgrade to vs2008 or 2010 to use your product.

The assemblies are built against the CLR2 framework, so in theory, they should work in VS2005. I encourage you to download the trial and test them out.

landerson999 said:

2) We have full support for our problems pertaining to updates as the last time we updated with Infragistics the version, we ended up with the .resx problem not being resolved for our projects being converted from 2003 to 2005, if you remember any of this...

Hm, I don't really remember a resx issue. Could you provide more details?

Once again, downloading a trial version and testing it out should reveal any major issues with the upgrade.

We try very hard to keep things backward compatible. But there are some things that are unavoidable when there are bugs that have to be fixed and some issues are just impossible to foresee in such a complex environment. As a general rule, though, any change in behavior which was not clearly a bug, is considered a bug and we should fix it.

landerson999 said:

3) We will need to find out if we are allowed to distribute the dll we are getting the error i mentioned above to our client, in order for him to use/call our modules...from delphi.

I'm not sure what you are asking here. My understanding is that the license you purchase from Infragistics is a developer license. You can distribute our assemblies to your users for free, as long as their use is limited to run-time. If they are doing any kind of development with the controls, they will require a developer license.

Your questions are more about policy than technical, so I'm probably not the best guy to answer them. You might want to try contacting developer support or sales for licensing questions. :)

Hi Mike, I think I have been able to get management to invest some money in getting updated with the versions of infragistics, however I need to clarify a few things before continuing with purchasing of next version(s). 1) Can you guaranty me that having the next version of infragistics will not leave us crippled seeing as we are using vs2005, and would not like to hear that we need to upgrade to vs2008 or 2010 to use your product. 2) We have full support for our problems pertaining to updates as the last time we updated with Infragistics the version, we ended up with the .resx problem not being resolved for our projects being converted from 2003 to 2005, if you remember any of this... 3) We will need to find out if we are allowed to distribute the dll we are getting the error i mentioned above to our client, in order for him to use/call our modules...from delphi.

Hi,

I'm still not really clear on exactly what you are doing and exactly what he (whoever he is) is doing.

But I can tell you that if you are writing a UserControl or something like that, anyone who is trying to use that UserControl for development of any kind would have to have a license for the Infragistics controls within it. So maybe this is the same kind of thing.

In such a case, I would expect the exe to raise a licensing exception, though, so that doesn't seem to be the case here.

Thanks Mike, will be downloading the newest trial version soon, and will be updating my project. What I was sayign about the references was, he was referencing my dll/tlb in his project, which my dll had been created on MY server with Infragistics installed, I sent him the dll by email, he then added the reference to it in his project on his machine (without infragistics installed), and then sent me the executable for me to test on my server...i guess i was wondering if he compiled the executable on HIS machined then sent it to me, maybe this is where the problem lies, as his machine does not infragistics installed..and if MY dll had that referenced ...etc, etc...hopefully you see where I am going with this, unless this is not something you have experience to answer...?