I have code from PowerBuilder 5 that can't be built. The compiler just stops before it is done without any error codes.
I would like to upgrade the code to the recent version of PowerBuilder but there are some intermediate versions of PowerBuilder that have binary dependencies to an old Microsoft java dll that Microsoft no longer can distribute due to some court case.
So, is there a way to get my code running in a newer environment?
/johan/
Firstly, you don't need to use "intermediate versions of PowerBuilder" to migrate up to a current version, so even if this java DLL dependency sounds questionable to me (at least it doesn't ring a bell), it's irrelevant unless it affects the target version of PowerBuilder.
For migrating, you might want to check out this migration guide, as well as a list of changes to PB that may affect you.
Very unusual sounding problem. You could give a try to migrating the code to a more recent version of PowerBuilder and see if it will compile or at least fail but give you some useful error messages.
I would also recommend posting this in the PowerBuilder section of the Sybase newsgroups. They are very active and full of some brilliant PB minds with lots of experience. You can find them here: http://forums.sybase.com
From here:http://forums.sybase.com/cgi-bin/webnews.cgi?cmd=item-4558&group=sybase.public.powersite
I just learned that the combination of "severe" message, and message
that psdwc70.dll was unable to self-register is probably because
msjava.dll is not present and/or registered on your machine. The
psdwc70.dll file relies on msjava.dll in order to install properly.
/johan/
Have you tried exporting the code in PB5 and importing in new version?
Related
I have a visualbasic application that interacts with several versions of software (Catia)
The Visual basic code is common to all versions of Catia software but it only works if the dlls of the correct version are referenced.
Is it possible to reference the dlls of all Catia software versions in the app (they have the same name) and to use the correct dlls after having detected the software version.
I understand that you have a compiled .exe referencing the catia-api.
I encountered the same problems with our applications.
Two solutions that worked for me:
compile separate .exes for each catia release you require. Means:
have one catia release running, then compile. Repeat with next release.
The -regserver should be done by Catia when starting (which I am not 100% sure about, you might still need to do the -regserver as C R Johnson explained).
Use LateBinding which means do not reference any catia-dll/tlb at all. Instead use reflection to call api-methods. This is a lot more effort when developing your app, because you cannot use IntelliSense. (As a workaround you could develop with EarlyBinding in only one Catia release. When finished, change your code to LateBinding getting rid of all catia-api-references.)
I don't think there is any simple way to work around this.
If you have multiple versions you just have to run CNEXT -regserver (as admin) in the BIN folder of the version you want before CATIA is started.
Even this may not prevent problems, as libraries which change or disappear between versions and settings may not be compatible.
I'm currently trying to compile an old program (made with C++ builder 2 or 3) with the "current" Embarcadero RAD Studio XE2.
So, I was wondering whether there is an easy way to use the old code, as Borland once claimed to be fully compatible to lower versions... however I couldn't find a "project-file", only source-code (.cpp, .h, .res, etc.).
I tried to "add to project" the main .cpp, however there seem to be some wrong include-paths... it also seem to use the OWL-package and includes its important source-files...
I'm a bit confused which type of main project I have to open first, since you need to open a new project before adding the source to it. As the running .exe has a GUI, I tried a Form-Window first, but it may be better to use a console or service as the real form is produced within the code as far as I understand.
So, after installing OWL and correcting the include-paths, do you think it should be running fine? Or is there something else to take care of?
If your old project was using OWL, you're probably well outside of the supported upgrade path.
That being said, valid C++ code should still compile and work and I've heard of people using OWL with recent versions of C++Builder. (via OWLNext)
Regarding your confusion as to which type of project to use, I believe a console application would be your best bet. A forms application is completely wrong, that will bring in the VCL and give you no end of problems trying to reconcile the different windowing systems. A service application is a completely different beast as well, and isn't meant for GUI applications. A console application should work, but you'll need more. The OWLNext project has a wiki that should help quite a bit.
I am going through a major crisis here and i would like to ask for advices.
I have been developing a game the last couple of months which is entirely based on lua scripting. The project is a cocos2d based project with the inclusion of the mclua library (more about mcLua can be found here http://www.grzmobile.com/blog/2009/12/1/integrating-lua-into-and-iphone-app-part-2.html).
Now i am nearly at the end of the implementation of the project and i just found out that apparently the version of lua that i use which is 5.1.4 does not have a goto statement which is of great importance to this project. The latest version of lua 5.2 however supports now goto statements.
My problem is that when i tried to add the lua version 5.2 to my project the library mclua throws a bunch of errors and it seems that this library doesn’t work with any other version of lua other than 5.1.4.
What can i do about this now? I was supposed to be nearly at completion of the project. Does this mean i am completely screwed now ?
Then you have a choice to make. You may:
Stop doing whatever makse goto "of great importance to this project". I've used Lua for a while and I've never needed goto that badly. Whatever you're doing can be done in some other way.
Modify this "mclua" library to fix the "bunch of errors" you get when you try to link it against Lua 5.2. Since you didn't explain what these errors are, we can't really help you in solving them.
Note that Lua's minor version numbers are not intended to guarantee backwards compatibile with prior versions. While the changes are generally relatively small, that doesn't mean that effort was extended to make code work in both without modification.
I have tried converting many projects from vb.net 2005 to vb.net 2008, and not a single one has ever made it. Why do you think they even bothered to include this tool if it is very clearly broken? I mean, it can convert some code okay, but I can never load Design view properly, and it'll almost never compile without error.
Whats the point in putting in a broken tool? I thought Microsoft products were always backwards-compatible? Do they have any requirements before running the wizard?
Generally projects won't compile because the compiler/language/environment has changed, not because there's anything wrong with the project files.
I typically use vspc to convert project files, but I'm usually converting them from vs2008 to vs2003, which Visual Studio cannot do.
I've never had any trouble with the conversion wizard, but I mostly use C#.
What specific errors do you get?
Also, do you mean from VB6? If so, here's the answer:
VB6 and VB .Net (any version) are quite different. The VB Upgrade Wizard will try to convert what it can, and show you exactly what still needs work.
If the conversion tool is actually broken (I've had mixed success using it in the past, with the success rate being inversely proportional to the overall complexity of the project), then one reason to include it anyway is to convince developers to start new projects using the latest version of Visual Studio, and not to start them with an older version and hope that the upgrade process will be seamless.
I'm not saying this is why Microsoft would include a broken conversion wizard, but you never know. If you'd like me to delete this answer, Mr. Ballmer, just let me know.
I want to update/upgrade the standard Leopard install of Sqlite3 to >3.5 to use the new sqlite_xxx_v2 methods from a Cocoa project.
I can't seem to find any information on how to do this. Does anyone have any tips or a site that outlines the update procedure.
Also is 3.5+ supported on the iPhone. I understand it's embedded so shouldn't be an issue...
What you want to do is grab the amalgamation sources from http://sqlite.org/download.html . Then just compile that into / add it to your project. You don't want to replace the system sqlite- that'll have unintended consequences in other applications. Plus, I'm pretty sure the system sqlite isn't a stock sqlite... Apple has probably made their own modifications to it that core data relies on.
You can read up on the amalgamation stuff here: http://sqlite.org/amalgamation.html , but in short: '''The amalgamation is a single C code file, named "sqlite3.c", that contains all C code for the core SQLite library and the FTS3 and RTREE extensions'''
I'd also suggest not using the sqlite calls directly, they weren't designed to be used that way (says the author of sqlite). Instead, there are a number of cocoa wrappers out there, including fmdb: http://code.google.com/p/flycode/source/browse/trunk/fmdb/ (which I wrote) :)
-gus
You don't really want to upgrade the system version of SQLite on Mac OS X. The reason is that all Mac OS X software is qualified against the versions of the packages that it includes, as built by Apple's build process. Installing a different version of a package, or even building the same version yourself but doing so slightly differently than Apple does, may result in a system that behaves unexpectedly.
Finally, if you embed a newer version of SQLite — or any Open Source library or framework included with Mac OS X — into your own application, you should be sure to integrate the Darwin changes for it from Apple's public source site. That way you can be sure you'll get as close to the same behavior as possible from the library you've built yourself as the version Apple ships, which is especially important when it comes to functionality like file locking in databases.
I don't believe i've updated my version, but it's currently at 3.4.2, and i'm able to use the new methods with the current version.
And i'm running 10.5.5 with the latest (public) iPhone SDK.
It would likely be easier to just drop the library into your project and link it in from there.