Console and GUI app in one!

I’ve been writing a module which allows for console applications to be created without a Xojo console license, and unlike Xojo, to allow console applications to interact with GUI applications.

Any help with the ReadConsole api itself would greatly be appreciated since it’s not returning a value to the buffer.

Here is the current demo code, which creates a console at startup, asks the user for their name, and after supplying the name, should set the GUI Window’s Title to the users name. I have managed to test my code in C++ and VB6, and it works fine, although Xojo seems to be a bit tricky with this one API declare and how it interacts with the buffer…

http://www.xojodevspot.com/demos/SimulanicsConsole.xojo_binary_project

Thank you for any and all help in solving the issue.

-Matthew

You need to preallocate the ConsoleBuffer memoryblock. I used

Dim ConsoleBuffer as new MemoryBlock(256)

And, lpNumberOfCharsRead needs to be ByRef.

Those 2 changes and it works.

[quote=64889:@Tim Hare]You need to preallocate the ConsoleBuffer memoryblock. I used

Dim ConsoleBuffer as new MemoryBlock(256)

And, lpNumberOfCharsRead needs to be ByRef.

Those 2 changes and it works.[/quote]

As so?

Declare Function ReadConsole Lib “kernel32” Alias “ReadConsoleA” (hConsoleInput As Integer, lpBuffer As Ptr, Byref nNumberOfCharsToRead As Integer, lpNumberOfCharsRead As Integer, lpReserved As Ptr) As Integer

Got it :slight_smile: I put byref on the wrong variable. Thanks Tim

Well, that’s gonna leave a mark.

Its not really a “console app” at any rate
A console app would run without a user logged in
Pretty sure this won’t
I get a 404 when I click the link so I can’t test it

I pulled the source until I can finish the module. It works perfect so far and can run without the user logged in…apps can create a console instead of gui windows or create windows then attach a console to them for interaction between the two. They can also be invoked from cmd.exe and interact with the shell :slight_smile: update soon with latest source…

Here is “Simulanics Console Magick” 1.0 Beta. I am still working on further functionality such as SetCursorPosition/GetCursorPosition and much more. Included is a demo source that uses the SimConsole class, as well as the manifest utility used to “convert” applications to console mode. Also included is 2 compiled demos.
Demos:

  1. Cannot run from a shell/cmd.exe, rather initializes it’s own Console process and can be Console, GUI, or Console and GUI. - Initialization(FALSE)

  2. Can run and interact from a shell/cmd.exe, and will load in the parent process(shell/cmd.exe) (like a regular console application). If a parent process does not exist, the application will spawn it’s own console process during execution - Initialization(TRUE) This method requires the “Simulanics Console Magick Utility” to create the ASM side-by-side manifest to “fool” the system into thinking that the application is a Console app rather than a GUI app; since this cannot be changed after build. *The magic of this happens during initialization when the Load ASM Manifest apis are used. The utility will create and place the manifest in the applications “Libs” folder. If it is not present, the application will fail to load since a console process cannot be allocated. Since the Xojo application is “natively” a GUI app, the app can be a standalone “native” console, GUI, or both. :slight_smile:

Source:
http://www.xojodevspot.com/demos/SimConsoleMagick.rar

Being a beta, please test it out, and let me know what you all think. The beta will cease to function at the end of the month, by which time, a new release should be ready.

Spawned from a console, and loaded in the parent console/shell itself…

Is adding the functionality in a class, which everyone asks for, “competing with Xojo”? In this case, wouldn’t creating anything (like web service api classes) be competition? In Xojo it seems that “if the solution is elegant and re-usable” it is “not okay” or raises “hey, that’s cool but we prefer you not provide that as a solution for anyone…Let them suffer out the roadblocks themselves…that’s why we charge for help” (we want your money…not REAL solutions)… even if no EULA is trifled with, and inherent system API’s are used… finding solutions for Yall (community as a whole)…i always get “spanked” by Xojo (I got spanked in an email today…). I don’t want yalls money, I just want to help. I mean, I enjoy helping everyone, and finding the solutions that aren’t “readily available”…but I will have to back away and tend to the other communities after this solution, where REAL stewardship for the community exists. I have helped drive hundreds, if not at least 1000+ new developers to Xojo, almost regrettably (your welcome Xojo). And quite a large portion of yall, have gotten to know me through here and aiding you side-by-side. The only money to be made from Xojo lies in creating software for the end user, but if you provide solutions to developers, you have a 50/50 chance of “just wasting your time” when Xojo says "we prefer you not help in this solution, let them suffer; they can empty their wallets and we’ll be glad to help “find a solution”…or they’ll move on to another project and no solution will be found. " I cease the solutions on my own accord because I respect the Xojo Developer’s wishes.

Numerous projects I’ve migrated to other cross-platform languages, so the projects don’t get stopped, or hindered in any way shape or form, Xojo just doesn’t get the honor of having “made with xojo” stamped on my final product. This being counter - productive since their name isn’t “getting out there.” When 10,000+ people download my software in a single week and see made with lazarus/c++/or genexus (to name a few)…Xojo is not in their minds at all…just a thought.

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.

Matthew, It just doesn’t look like you’re coming from a good place with this. You’re obviously talented and there are a whole lot of things you could be doing that are (a) profitable and (b) coming from a good place. Serious developers don’t begrudge anyone making money, because that’s their racket too. Additionally serious developers look at “good of the community” arguments and intentions and roll their eyes.

I’m sure the worry is a lot less about this “competing” with Xojo than just becoming another ElfData style cluster-frack, where a lot of developers who don’t know any better buy into a complete junk product and then there’s a bunch of arguing over low level changes that the developer of said product should have just dealt with on his own if he wanted to tie in there. Years later, there are still people using that thing and now running into developer’s unwillingness to even claim ownership for a licensing audit.

But I speak for nobody and know even less. I just call it as I see it…

[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:

  1. 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.

I would say build your own Xojo.

I would say he’s rather stuck on himself. Probably likes the way he looks in the mirror too.

That was inappropriate. How old are you? If you don’t have anything nice to say, it is best left unsaid.

If I was stuck on myself, I wouldn’t bend over backwards to freely help anyone and everyone here. Minds are like parachutes, they only work when they are open.

I’d guess that response has much to do with the claims you laid out that appear completely unrelated to this topic
But that’s just my guess