We have a collection of commercial MFC/C++ applications which we sell using Stingray Objective Toolkit, we have source code license and have ported it in the past to Solaris/IRIX/HP-UX/AIX using Bristol Technologies WindU (Windows API on UNIX, including MFC).
Any long story short recently about 18 months ago we ported Stingray to Win64, but a long a tedious task, during this time I did some research on commercial and open source alternative MFC extension libraries things like Ultimate Toolbox and Prof-UIS.
Has anyone else used Stingray and moved to an alternative?
If so which one would you suggest?
What were the main perils of the move?
Yes, we haved moved away from Stingray. It depends on what Stingray components you are using. For the grid control, you can use the free MFC gridcontrol from www.codeproject.com or the commercial one from http://www.bcgsoft.com/. The free one is OK but development has stalled, so no modern UI rendering etc.
The 'layout editor' Stingray component can be replaced by the one from bcgsoft.com, but I don't have experience with that - we rewrote the functionality we needed from that on our own (it was only a subset of what Stingray provided).
As for alternative MFC toolboxes, I suggest bcgsoft because part of their toolbox is in the Visual Studio Feature Pack so it's free and fits very well with VS. I have looked at Ultimate Toolbox (stay away from it, stale code that isn't updated anymore) and Prof-UIs (OK but I found it not so easy to integrate).
Now that BCG is part of the 'official' MFC I don't see a reason to choose something else than BCG (except for maybe the cost, if you need a free alternative you can look at codeproject).
I have limited experience with Stingray.
However, I want to suggest trying CodeJock's Xtreme Toolkit Pro (http://www.codejock.com). Its GUI is very good and its supported very well.
I have been using Stingray for last eight years or so, and have looked at moving off it a couple of times. So far, I've decided against, principally because I have ported a version to Windows CE & Mobile and don't see much else giving the same solution on this platform. While Stingray isn't perfect, they have now got a 64bit version, and it's a pretty stable product.
What I am doing, is replacing the very weak areas of Stingray, such as the XML support, with alternatives. In this case I went with Expat for performance reasons.
The perils of moving? You could go from something stable but old fashioned to pretty but flakey ;) In my case, I would also kill a fair number of my automated test scripts that work at GUI level.
Edit: Just to add a bit to the above, I moved from VS2003 to VS2008 this week and at the same time Objective Studio 2006 v2 to Objective Studio 10.1. The transition was pretty seamless, with one minor glitch that was promptly handled by RogueWave tech support. Even this would have gone unnoticed if we didn't have a very extensive GUI regression test suite. IMO, Stingray is a very mature, well supported, feature rich and most importantly stable product. I for won't be moving of it any time soon without very good reason.
Related
i'm facing a challenge of rebrushing and updating an almost 10-years old Screenweaver project, and looking for a decent modern swf-exe convertor. Don't have much time to evaluate all the options, therefore i'd like to hear responses with actual working experience with such a tool.
Since WinAPI interaction is a must, the default projector is not an option.
Similar questions (no concrete answers there)
Package SWF into an EXE or APP
Create an EXE from a SWF using Flex 3 without requiring AIR?
Many thanks
UPD: 300 bounty for anyone who can help me with a practical answer.
I've been experimenting with different SWF projectors for a long time now, and so far I think I've tried most if not all of them. I've explained in more detail the best projectors I have used below.
MDM Zinc
http://www.multidmedia.com/software/zinc/
I remember back in when I had Vista that MDM had quite a few bugs running under that OS. It took a while for them to fix those bugs - the bugs didn't stop it from running, but really interfered with the functioning of some methods in the program. For this reason, I decided not to continue testing Zinc and moved on to another projector. Saying that though, I'm certain they have fixed those bugs now.
The program itself has a nice intuitive interface, and allows you create screensaver as well as EXEs (which is obviously good for you).
The product is pricey - currently at $349.99, so this put me off.
You can also generate Mac and Linux projectors which is very attractive, but requires an additional license for each which does cost a lot of money.
SWF Studio
http://www.northcode.com/
This was one of the projectors I really enjoyed working with. It's fully featured, has great community support and the developers are always on hand to help. The projectors it generates are compatible with all Windows operating systems, and I've never had any problems with bugs on this one.
Northcode also offer a student license for SWF Studio for $49. I nearly purchased a license with these guys but the only reason why I didn't was because I found another projector which was better for my scenario which I will come onto in a moment.
I can tell you that one of the reasons why I didn't use this projector (it does sound trivial) is because it had a large file size. SWF Studio allows you to select what size projector you want in terms of filesize - with options like tiny and compact I think but the smaller file types might have dependencies with other files in the directory. This means that you would have to bundle your application with some folders and additional files as well as the EXE itself.
SWF Studio also has the option to create screensavers.
mProjector
http://www.screentime.com/software/flash-projector
mProjector has gone up a version (from 3 to 4) since I last used it, so it may incorporate a lot more features in this version. I remember that the product is very good with transparency, and showcases some 'screen buddies' which use transparency to virtually walk about your screen. The reason why I didn't use this projector is because it didn't have as many Actionscript functions as I would have liked, but I believe it has a lot more nowadays. In your project this wouldn't be so much of a problem because you want a screensaver.
It is reasonably priced at $399 for both Windows and Mac compatibility, but you can buy just Windows or Mac if you wish for a cheaper price.
Janus Flash
I was going to explain this product in more detail but I have now realised that the website no longer exists! Janus is the projector I liked the most and ended up using because of the sheer amount of features available for use in your code.
Like all the projectors I have mentioned above, each one adds functionality to flash which you don't usually get with an SWF. Each product includes pre-built actionscript methods which can interface with the operating system itself to do things you can't do in the Flash sandbox. For example, each one of these projectors allows you to manipulate files (add, edit, delete e.t.c.) on the computer. Janus had the most methods available out of all the projectors I tried. This is partially because Janus used the .NET framework (which meant that .NET 2.0 was required on the system you were executing the projector on).
Also like MDM Zinc, this product allowed you to create applications for the Mac too. I managed to get a cheaper price too when I contacted them directly explaining that I was a student. I recently contacted Janus-Flash to ask about the future of the product, and they said that they may re-release Janus in the future, but for now it's off the market.
Some other products I have used which are worth a mention but I haven't explained in detail: SWFKit, Jugglor, F-IN-BOX (more developer releated as it required cutting code).
A quick search brings up these which might be worth a look: Flash2Me, Flash EXE Builder and SWF to Screensaver.
For your project I think the best option would be SWF Studio. It has lots of nice scripting features you can use to interface with the OS, and is nicely priced too at $299 for a full license.
I hope this helps in your decision for what projector to use, and will save you from trying out many different projectors like I did over several months!
We support a lot of Win32 functionality directly in our core API so chances are you may not even have to make a direct API call, but if you do...
SWF Studio has an advanced Plugin API that allows you to write custom plugins in C++, C# or VB.NET so you can call win32 or .NET functions. We created our own ummanaged to managed code shim so you can write a native .NET plugin and call it from SWF Studio just as easily as you can write a Win32 plugin.
There's no difference between how you call a SWF Studio function in AS2 or AS3. We have maintained 100% backward compatibility in our API. Whether you're using AS2 or AS3, your calls will just work. And they'll continue to work.
However, the place we really shine is support. I created SWF Studio and I'm still in the forums EVERY day answering questions and fixing bugs.
My experience here is from a year ago.
Having worked with mProjector I can tell you that the AS3 API is quite robust and easy to use. I was able to wrap a large swf-based project using external assets up into an EXE without a lot of problems. The UI for mProjector's project gui leaves something to be desired, but the actual hooks to the file system were easy to use.
The difficulty is that not all of it is documented. In fact there were as of a year ago a lot of undocumented packages.
My only real problem with mprojector was that in AS3 there wasn't any support for SharedObjects. Someone in their community worked around this and made their solution available. It does of course make use of storing a file on the local system.
This overall compared favorably against Zinc which was extraordinarily complex, slow to compile, and worse than having no documentation all the docs I needed were flat-out wrong.
I ruled out Jugglor almost immediately. It never successfuly compiled anything.
Since this is an old project you're talking about, and written in AS2, I can't speak to that side of it. I can say however that programs like Zinc and mProjector have been around a lot longer than AS3 has, and that the same hooks that are available in AS3 seemed to be available in AS2 also. The possibility exists that there may be more such hooks in AS2 since it's been supported for longer, but I cannot vouch for this at all.
I have used all of these applications, but most of all I liked theFlajector - a program that converts flash movies (swf) to exe files. You can include a flash player in generated applications and they will use it. In other words, the applications will work even if no flash player is installed. Also, Flajector can create windowless applications from flash movies. You can extend your applications using plugins. Using standard classes you can work with files and more.
I'm looking for feedback from .Net developers who have experience with Aldon as a lifecycle management platform. We're seriously considering using Aldon for lifecycle management including source control, automated builds, etc. I know there are a lot of other options out there, but ours is primary an AS/400 shop (with AS/400 programmers outnumbering .Net developers 6 to 1), and Aldon is used already by our iSeries team. The benefit we're looking for is having one lifecycle management suite.
Basically, I'm looking for opinions from people who have used Aldon and another set of tools (perhaps TFS, or a combination of SVN, Cruise Control, etc). If you've worked with both, do you have a recommendation on whether this is a good idea, or a bad idea? It's obviously a big choice, so any feedback would be helpful.
Edit - Added
No answers or comments... AND my first Tumbleweed badge. I'm not sure if this is just a bad question, if nobody actually USES Aldon to manage their .NET work, or if there's just nobody using Aldon that used other products and can offer a comparison.
So, I'm offering a bounty to sweeten the deal, and broadening the scope of the question... If there are any people out there USING Aldon at all, can you provide any information on issues you have had, is it a good suite of tools, frustrations, or gotchas, things you love, etc?
Added -even more
Our primary goal is to have one product to manage both our .NET and our AS/400 (primarily RPG) development. If you have a suggestion for a different suite of tools, or have tried it and decided it isn't worth it, I'll take that answer as well.
I'm working in a shop similar to yours--in our case, there is a substantial legacy code base of iSeries COBOL code, and a growing number of .NET systems--and the .NET developers have successfully lobbied to use Subversion for source control. In my admittedly brief time evaluating the product, it seemed like Aldon was not very flexible at all in areas like branching and tagging, and has a very cumbersome and arcane interface. Since product lifecycles are (mis)managed separately in our shop anyway, limiting the .NET use of Aldon to source control only, it was a simple decision. In the .NET world, Aldon lags far behind the standard open source tools in features and usability, and has no hope of competing with TFS. In our case, managing .NET code outside of Aldon has definitely increased developer productivity and decreased frustration.
One example...coming from a Subversion shop, I was trying to find out how to create an experimental branch in Aldon. If it is possible at all, the documentation did a great job of obscuring the feature, and our Aldon admin had never come across the concept. Everything in our shop is locked down tight, with admin rights needed to create projects, versions, etc. This might be worthwhile from a lifecycle management standpoint, but from the perspective of a developer trying to get work done, it is a killer. I don't think lifecycle management and source control belong in the same software, and Aldon has done nothing to dissuade me from that opinion.
I think you will find nobody here uses it. .NET people fall into two categories - those that are "cheap" (i.e. trying to save costs) and then basically you look or something like open source. And those who pay a lot, and most of those go with Team System - because it is ingtegrated into Visual Studio from the bottom up. AS/400 is a pretty rare intermix for .NET developers, so, at the end - you possibly are just out of luck.
I Personally am not sure I would even bother with it. THere is a lot more to soemthing like Team System than tracking source etc. - lots of good testing features, build in continuous integration etc., and all that without running through hoods in order to - well - get then an inferior product.
We encountered the same problem at my workplace a few years back when we started up our first .NET project in the midst of a bunch of RPG developers. At the time, we chose to use a separate source control system (Subversion) for anything written in .NET (or for anything else that somebody wanted to use it for). We moved all of our projects (.NET and AS/400) into Gemini for time and defect tracking purposes. Basically, we chose a single product to manage our .NET and AS/400 projects at a high level but different tools for version control, automated builds, automated testing, etc.
Years later I can happily say that this has worked out quite well for us. I really can't think of any issues this has caused - but can attest to the fact that it has avoided some potential headaches and butting of heads. I do think that you will have an easier time finding (good) .NET developers by choosing a widely used version control system. I can't speak for anyone else, but for me the use of a version control system I have never even heard of would be a bit of a red flag in an interview situation.
We've got this large application written in Delphi 5, and development is ongoing to this day. There is research going on into migrating to newer versions, but so far there is no success, as some 3rd party components have not been updated in ages and do not work on later versions.
In the meantime however people need to continue work on it. Now Delphi 5 IDE is no real treat. It's pretty bug-ridden and lacks a lot of features of contemporary IDEs which makes it difficult to use. Especially when it comes to debugging.
So I was wondering - would it be possible to use Visual Studio in the process? As far as I know the .PDB file format is pretty old and is well documented. Could it be possible to make the Delphi compiler to somehow generate a .PDB files for it's compiled results? Then the program could be debugged with Visual Studio, possibly to a much greater extent than in the original IDE.
Well, the absolute Holy Grail would be to move all development to VS, just keeping the compiler from Delphi, but I imagine that would be pretty impossible.
No, and neither can any other version of Delphi. You can use Map2Dgb to turn a detailed map file into a dbg file, though, and you can use that in WinDbg.
I'm curious what debugging features you're expecting to use in Visual Studio that aren't in Delphi 5 and that also don't rely on the IDE understanding the Delphi language. I was always rather pleased with Delphi 5.
BTW, you can vote for this feature here.
Note, that VS-compatitible debug info will be useful not only for debugging application (I agree: it's better to use Delphi), but it will be useful for using tools like Process Explorer. For example, Process Explorer may be able to show human-readable call stack, instead of RAW numbers.
I've tried tds2pdb and it works great for me.
Apparently you can't. Seems that PDB is after all a propieritary Microsoft format without documentation, and as such there are no other tools generating it. Pity. :(
I would recommend moving to a later version of Delphi. We have done this with various applications for clients. Moving to a newer version of Delphi is normally straightforward, but there were issues moving from D5 to D6 due to changes in the way components were handled (design time code being separated from run time) and the change to Unicode in D2009 was a bigger change.
The main thing is to sort out the third party components. We only ever use third party components that come with source so if the worst happens and the vendor disappears, we can still work on the components ourselves.
Which components are causing the issues?
I saw that Beta 1 of VS2010 was publicly availible.
My question to those of you who has tried it is: does it work good?
Will it cause my computer to blow up in tiny pieces? Will it crash randomly? Will it work with some minor glitches? Or is it just perfect from bottom up?
I'm only coding school- and hobby-stuff, so nothing that someones life depend upon, but i still want software that works. How close to a final product is it? Is it worth trying?
It's a bit slow, and there's no offline MSDN, but it's worth trying IMO. Having said that it's slow, I still use it on my NC10 netbook, so it's clearly not that bad :)
I've got it side-by-side VS2008, and that hasn't caused any problems.
I've seen a couple of glitches (once the keyboard handling went completely wonky) but it's certainly usable. The main question is what you want to get out of trying it - in my case I absolutely need to code against C# 4 to explore the new features. I do most of that from the command line in fact, where the speed of VS obviously isn't an issue, but it's nice to see the VS-specific features as well (like the debug threading views for Parallel Extensions).
It seems more or less usable on the .NET side. The C++ side is a bit more sketchy. On one hand, they've added support for some very nice new C++0x features, on the other, they've broken some absolute fundamentals.
Your plain old main function won't compile in 32-bit with unicode enabled. (Workarounds: Either compile as 64-bit, disable unicode, or rename the function to wmain).
This seems to me to be a strong hint that the C++ side of things is nowhere near release-worthy. I'd probably wait for beta2 before doing any serious work with that.
I would say it is great, but the performance hurts a bit.
Here is an idea for you: Install it into a VirtualPC. Then you can play and not care what it does. You don't like it, delete the VPC image and keep on trucking. That is how I play with Microsoft betas now. I never install them on any real machine - too risky.
Usable: Yes.
Recommended: Not if you'r a touchpad-addict or dislike crashing apps.
I've been trying it for 2 weeks now coding small C#-projects and these are my impressions
Reasons to use 2010:
Looks good
Multi monitor support
I can see myself using the code templating but right now i couldnt find any really useful stuff except for reducing the fontsize of comments.
Zoom in the editor
Select a variable and then press shift+up/down to go to next usage of this variable
Ctrl+, brings up instant search of classes and functions in the entire project. (i've become really addicted to this)
Floating watches for single objects
Reasons to not use 2010:
TOUCHPAD SCROLL DOESN'T WORK IN THE EDITOR!!! (this is reason enough to not upgrade if you are using it on a laptop)
I've had some random app-crashes in the middle of just writing code, once or twice per day maybe.
UI sometimes freezes randomly for about 30seconds and then returns to normal.
It started to use 100% CPU power from one of my cores once when it was minimized in basic editing-mode and i was doing other stuff in other programs, i only noticed it because the fan started to go wild.
Otherwhise it's pretty similar to 2008. I haven't noticed any difference in speed like other people say.
You need to ask yourself: what is the advantage for you in using VS2010 over VS2008? I would suggest that there is no advantage if all you are doing is "school- and hobby-stuff".
I'm still using VS2008 for business related stuff (and, indeed, VC6 for some stuff). I prefer to wait until all the early adopters have tested it (and Microsoft has released at least one service pack after the real product release) before I do their testing for them.
It seems to co-exist with other versions of VS without causing any problems.
Regarding the slowness - it seems to be the UI that is slow, rather than building. Once it's going it doesn't seem much slower on my fast quadcore. I've yet to try it on my laptop.
It's usable enough, the small glitches that I've encounter weren't that bad. However, certain VS extensions(like XNA) don't work in VS2010 at the moment.
It's fun to toy with. Not usable for me, cause re#er does not support it yet (had to install TestDriven .NET which works through keyboard shortcuts only to run my tests).
Gave me an insight how addicted I am. :/
Btw, on Win7, without virtual pc it seemed even faster than vs2008 for me.
VS2010 doesn't yet support mobile device projects, which might or might not matter to you.
VC++ wise - VS2010 has a built-in 64-bit compiler, VS2008 does not.
You can supposedly add 64-bit support to VS2008, but it takes some effort.
I've been using VS 2010 beta (with .NET 4.0 beta) on Windows 7 RC. I've been trying to rewrite parts of a large-scale business application in it to see what can be done with it.
The UI freezes frequently. I'm talking 1-10 minutes between freezes. The UI does not come back, so I'm forced to kill devenv.exe every time it happens. Microsoft probably puts my error reports in their spam folder by now.
For me, VS 2010 beta 1 classifies as unusable. However, it's fast, the new IDE functions are very handy, and it's pretty. I keep coming back to it despite my resolutions to wait for a stable build.
Does anyone know (with confidence either way) if Microsoft plans on continued support (as in compiling) the legacy (2003) deprecated (vs2005/vs2008) Managed C++ (MC++) Syntax to target the .NET CLR in C++ code?
Microsoft officially deprecated the /clr:oldSyntax with the VS2005 C++ Compiler (Orcas); and thankfully the VS2008 C++ compiler still supported the /clr:oldSyntax switch.
But will the C++ Compiler with VS2010 still support it? Or will the release of VS2010 finally break the backward compatibility with the /clr:oldSyntax?
I need to know before VS2010 is released for project planning scheduling and can't find the official word on the MSDN site or MVP sites?
If you can't find the information on MSDN or MVP, then it's probably a good idea to ask Microsoft directly here (the C++ ones, I'd guess). I don't work for Microsoft but I do work for another (very) large organization and we developers monitor public fora very closely. I suspect there's quite a few MS developers who would be watching that site.
However, if you're doing project planning without risk management and contingencies, you're not doing it right.
You should allow for the possibility that it will not be supported and do one of two things.
have an item in your Gantt chart to allow for the re-engineering.
have a risk log that clearly states re-engineering may be necessary.
From my experience, the first is usually better since, if you find you don't have to do it and the schedule is slipping, you can just drop that item to catch up. Sometimes you can drop it anyway and deliver sooner, just to make yourself look better for your annual performance review :-)
But even if you don't allow for it and then find it's necessary, the risk morphs into an issue and you can go to higher management to explain why more time is needed. You're covered since it was made clear in the risk log - it then becomes their decision to allow you more time or keep using a back-level of MSVC.
Keep in mind that if you don't have to do it, you probably still should consider it (sans schedule slippage). Microsoft didn't deprecate them for a laugh, they're going to disappear at some point. Although YAGNI suggests you shouldn't worry about it unless it's imminent, it would be prudent to do some work on getting ready for it.
That will avoid the last-minute mad rush when Microsoft finally do remove the functionality.
It seems to be supported - see VS2010 beta 2 documentation for /clr.
Well, you can check out the CTP bits. That's not a guarantee of what will be final, but it's a good idea. Doubtful there will be any big compiler changes at this point.