By Andria Jensen - 8/21/2006
Should I be okay to upgrade to DevEx 6.2, or will this cause problems with the inherited controls since they are compiled with 6.1.5?
|
By StrataFrame Team - 8/22/2006
If you upgrade to 6.2, you'll need to download the source code and change the references in the source code to 6.2 and then rebuild it. You'll only need to rebuild the source code project for the MicroFour StrataFrame Inherited assembly.
|
By Andria Jensen - 8/22/2006
Any idea how long it will might be until you guys have the wrapper available?
|
By Trent L. Taylor - 8/22/2006
We can recompile this for the 1.5 release. But I doubt we will do anything before then. You can do this yourself relatively easy. You already have the source code for the wrapper. Basically all you need to do is install the 6.2 version of DevExpress and then open the DevExpress wrapper source code and change the references to the 6.2 assemblies and then recompile. You should then be good to go 
|
By Andria Jensen - 8/22/2006
Ok, I'll give it a try when I get brave. Thanks 
|
By Trent L. Taylor - 8/22/2006
LOL....you can do it 
|
By Andria Jensen - 8/29/2006
I can't recompile because I am now using the new dll's you guys had for the training. I recompiled my BO's to work with the new stuff and don't want to go backwards now. So am I just stuck waiting for the new StrataFrame release until I can use the new DevExpress release? If so, that's fine...just wanted to make sure there wasn't some other way around it.
|
By Andria Jensen - 8/29/2006
Well, rethinking this....If I only have to recompile the Inherited UI part of StrataFrame I should be okay using it with everything else being the 1.5 pre-release right? Or is it safer just to wait? I'm anxious to get the DevEx stuff because it fixes a few things I've been waiting on to move forward.
|
By Trent L. Taylor - 8/29/2006
If I only have to recompile the Inherited UI part of StrataFrame I should be okay using it with everything else being the 1.5 pre-release right? You are correct. The inherited stuff has not changed in a while and regardless, this will not cause you any problems with the rest of the framework since it is all inherited. Or is it safer just to wait? You can always get back to where you are quickly by loading the version from the training class. Go ahead and go for it
|
By Andria Jensen - 8/29/2006
I must not be doing something right. I am getting the following error message on the build:The command "c:\AfterBuild.bat "C:\Program Files\MicroFour\StrataFrame Source Code\MicroFour StrataFrame Inherited UI\bin\Release\MicroFour StrataFrame Inherited UI.dll" "C:\Program Files\MicroFour\StrataFrame Source Code\MicroFour StrataFrame Inherited UI\bin\Release\MicroFour StrataFrame Inherited UI.xml"" exited with code 9009.
|
By Trent L. Taylor - 8/29/2006
The AfterBuild.bat file is not located on your C:\ drive. Just copy the AfterBuild.bat file from the root folder of the source code projects and copy it to the C:\ drive and you will be good to go.
|
By Andria Jensen - 8/29/2006
I think I'm still having some issues with the two different SF versions. The Inherited UI I have source code for references the Base and Business dlls of 1.4. If I try to use the 1.5 Base/Business dll's I get a few compile errors when I try to compile Inherited UI.
|
By Trent L. Taylor - 8/29/2006
What are the errors?
|
By Andria Jensen - 8/29/2006
Specifically, I get an error on this line in BrowseDialogWindow.vb:BuildDataTableFromEnum( GetType(BrowseDialogAllSearchTypes), SortOrder.Ascending, CType(loCombo, System.Windows.Forms.ListControl), New String() {"Equals", "GreaterThan", "GreaterThanOrEqualTo", "LessThan", "LessThanOrEqualTo"}, False)Basically the error is saying that this overload is not right, it doesn't accept these arguments. Also, in ComboBoxEdit.vb I am getting an error saying that EnumSeparateOccurences and EnumTreatNumberAsCap are not implemented for the IListControl interface. If I can fix these I can build no problems.
|
By Trent L. Taylor - 8/29/2006
You are right...we changed the overloads. Just add a False, 0 or a 0, False at the end and rebuild. Then you should be OK.
|
By Andria Jensen - 8/29/2006
what about the two interface implementations? Is it okay to just leave those as the empty shells for right now?
|
By Trent L. Taylor - 8/29/2006
Yes, you aren't using those right now anyway.
|
By Andria Jensen - 8/29/2006
Great, I have it working now! Thanks for the help.
|
By Trent L. Taylor - 8/29/2006
See...I told you that you could do it!!!
|
By Andria Jensen - 9/6/2006
It works great on my machine, but today another developer is trying to use the dll I compiled and is not successful. Is there something else that must be done besides copying the Inherited UI dll to his machine? We registered it with the GAC as well because I thought this was the problem, but doesn't seem to make a difference. I'm getting errors on all my forms when I try to load them in the designer because of properties or changes with 6.2 that Inherited controls don't understand. So it seems like its definitely that Inherited UI dll, but just not sure what's different on my machine besides I built it on my machine and he just copied the dll over. Is there something else I need to do on his machine?
|
By StrataFrame Team - 9/6/2006
No, there isn't anything else that needs to be done... as long as you replaced the references within the Inherited UI DLL to 6.2 and rebuilt it, then it should work for everyone that has 6.2 installed on their computers. If you registered the DLL in the GAC, then it might be the case that he does not have the exact same version of DevExpress installed on his computer, or he has more than one version (6.1.5 and 6.2, maybe?).
|
By Andria Jensen - 9/6/2006
Yep, you were right. We uninstalled 6.1.5 from his machine and everything magically worked. The weird part is that I have both versions on my machine but don't have problems. I figured it's something to do with me building it on my machines that is allowing me to avoid the issue. Oh well, it's fixed...I should've asked 3 hours ago 
|
By StrataFrame Team - 9/6/2006
.NET resolved some of the "DLL hell" that you had with the old Win32 stuff, but it introduced a whole new group of problems
|