[quote=65538:@Phillip Zedalis]I think Xojo can be put on the defensive rather easily given my own experiences.
That aside this particular projects serves little purpose other than to circumvent the Xojo licensing scheme.[/quote]
In native xojo, can you attach a console to a window/gui? It is quite a handy for debugging, adding control sets to consoles (and can be done dynamically without 100+ lines of code and implementing constructors), implement a single application that can act as a console or gui application by using command line parameters (without writing 2 totally separate applications…counterproductive and can pose numerous bugs between the two separate applications). Ever try to step through debugging a mousemove or paint event (good luck)? Can you implement a Shell class with its mode set to interactive and see and interact with it without having to write a “complex frontend” to the shell/console using textarea and textfield? Or load a console directly into a gui application and embed it into a container control? Xojo only allows for a console OR gui application, and to implement some of the above, havoc is wrought when attempting to achieve just a few of the mentioned using apis to interact between 2 separate console and gui windows, since they are 2 separate processes (rather than in a single process as my solution gives). Ever try to use windows Findwindow api with 2 separate processes? Easy… now throw another instance of a console in and windows will ‘randomly’ choose the process since it cannot differentiate between the two. try this, create 10 instances of cmd.exe, now write code to send commands to the 3rd, 7th, and 10th windows. Did you spend weeks…months trying to do it and/or ever find a solution? Now use my class, spend 10 minutes, and viola, task completed. I can’t think of any mac or Linux apps that require console and gui interaction of the top of my head, but I can name at least 2 dozen without hesitation… If I meant to circumvent licensing, I’d write the apis for Linux and mac to make consoles (which could be done just as easily). Mac can interact a console and gui using simple scripts, Linux provides an interface… Windows… Nothing but complex api coding (and you’re lucky if you get it working, seek out the last 12 forum posts where no solution was ever found…i believe they all but 1 or two used another language to find their solution…sad) if only xojo released a class that developers could use to verify that:
- the developer has a valid license with true or false for desktop, console, web, db etc.
then solutions could be developed for existing developers and let them use the solution based upon their licensing scheme. Heck even a few new pragma directives would do the trick!
Then, my class could “only” be used by developers with console licenses, but… counter productivity says rather than implement something like this for “solutions developers,” let the whole of the community suffer, the language suffer slight degradation, and developers move to other languages where no “solution blocks” exist, and the language is just as easy to learn and more “powerful” in this aspect.
Amazing how a few licensing pragma directives could solve almost every development solutions problem. Perhaps I shall put in a request. I don’t aim to be part of marketing or business, but as many have seen here and in my engineering feats at large, I know how to turn quarters into Benjamins, and land billion $ deals with companies (like Walmart recently), electrical, medical, security, and a few other fields I never thought I’d poke into over the last year. I want to see Xojo with developers in the millions like 2 yr old languages that are still new, not 80,000 developers over a 20 year period (rising and falling). One of my recent projects Simscript could change how developers create games, control arduinos, and add cross platform plugins to their applications, in minutes rather than days. …but I was left with the question “how would you ensure developers have a license. …etc”… simple pragmas. …that’s my solution to the Xojo framework, that I myself, cannot add… solutions should always be simple and elegant.