Francois's suggestion gets my vote, only allowing a change of build when you start isn't good, what if I want Vitalize and EXE ?
Francois's suggestion gets my vote, only allowing a change of build when you start isn't good, what if I want Vitalize and EXE ?
Ah yes fair point, but I would then say have sub groups. For example, If you choose win32 as your build type, you would get the sub options of Stand-alone Application, Vitalize! and Screensaver. If you selected Java, you would have the different types (cant remember all the types) I think they were stand alone applets, web applets and the version compatible with mobile phones (again, im not sure on those versions sorry). I would say allow you to change between different sub versions, but not the main build type.
Just my idea's anyway, im completely happy with however the devs do it, they've been in the trade far longer than myself!
What if a person wanted to build it under everything?
And thought ahead far enough to plan for this -- (always a good idea)
Now I can just change the build type and build it.
Anything else seems like a hassle.
While I know its a problem -- whats supported under Windows, Java, Vitalize and ect... I still think better information provided and replying on the programmer to plan it out is better then restricting the program.
It sounds like Francois has a cool idea to filter the objects.
This would be better then making people read pages on whats supported where
Thats very true, although I was under the impression that although CT are converting all their extensions, not all will be converted as CT don't have the source to all extensions, which could cause problems. I guess their are pros and cons to each solution, but yes, Francois's way is less restrictive than my idea. I was also basing my idea on the way that MMF was designed to be *simple* to use.Originally Posted by Jeff
It's a royal pain in the backside if you ask me.
Devs don't have to back up their source so if they lose it it's tuff for the rest of the community.
Can we get one or more of the CT devs to create another object that does the same so you could build a java version?
You would make the original object obsolete but you would have a java version.
You'd be crippling your java games and apps if you didn't do this.
DJFuego please understand that we are a team of 3 developers only! We have no time to care about external extensions! We have a big job with our own.
We will make the Java devkit public soon, and from then it is up to the developer to make his own Java version...
If you're making applications that use these external objects then you put your fate in the third party dev's hands. For most people this is okay, but if you really need long-term security then you need to be prepared to (a) write the Java extension yourself or (b) pay somebody to do it.
This is exactly what the owner of the third party extension faced when they made it for the native version - nothing has changed.
[quote=Francois]DJFuego please understand that we are a team of 3 developers only! quote]
Can't you get more?
They were a team of 2 developers not too long ago
Team of 2 at clickteam = a team of 20 in other companies, to be fair :grin: :crazy:
Posting Permissions
Reply With Quote