#! appname_yourname.xcf <PATH>/Applications/fourjs/fgl/3.20.10/demo</PATH> <DVM>"/Applications/fourjs/fgl/3.20.10/bin/fglrun"</DVM> <MODULE>"demo"</MODULE> <PARAMETERS/> #! appname_yourname_studio.xcf <DVM>"/Applications/Genero Studio 3.20.08-167272.app/Contents/MacOS/gsproxy"</DVM> <MODULE></MODULE> <PARAMETERS> <PARAMETER>--host</PARAMETER> <PARAMETER>127.0.0.1</PARAMETER> <PARAMETER>--port</PARAMETER> <PARAMETER>50457</PARAMETER> <PARAMETER>--console</PARAMETER> <PARAMETER>/Applications/fourjs/fgl/3.20.10/bin/fglrun</PARAMETER> <PARAMETER>demo</PARAMETER> </PARAMETERS>
… the file that ends _studio.xcf has gsproxy as the process launched and some arguments that include the program name. This .xcf ending _studio.xcf is the one you will see in the browser URL field. gsproxy acts as an intermediary between Genero Studio and the running instance of fglrun -d, and is used to pass the debugger instructions from when you click next/step in Studio to the fglrun -d instance, and in turn brings the variable values back from the debugger to Genero Studio.
If after the program has terminated you copy and paste the URL ending _studio into another browser tab, this will fail. The URL you need in this instance is the one that does not end _studio.xcf. So the two tips here are
- after running program from Genero Studio in browser, if you want to run it again outside of Studio, copy and paste the URL and remove the _studio
- this .xcf that does not end _studio.xcf is a close model of what a production .xcf should look like, I say close, a potential improvement is instead of repeating environment variables in many individual .xcf files, consider using an abstract application so they are only defined once.
Final point of operating systems is consider what servers processes are running on and how are they communicating. With GDC Direct Connection, we know that fglrun is running on one server and GDC is running on your local workstation. That is typically FGLDIR/bin/fglrun is running on the back-end Linux server and gdc.exe is running on your front-end workstation. FGLSERVER controls the port that fglrun communicates on, -p controls the port that GDC listens in. But do you know the present working directory of the gdc.exe executable? Why can’t FGL_GETFILE find a file, have you specified file absolutely or relatively, if relative what is it relative to …. This isn’t unseen Genero magic, this is following operating systems, if I am specifying a file relatively, what is it relative to?, and does the owner of the gdc.exe process have permissions to read that file etc.
I encourage you if necessary to draw a diagram of the various pieces. This diagram comes in handy with Genero Report Writer, in the architecture there are 3 pieces and so issues with fonts, images, files not found, normally come down to the fact not considering these 3 pieces (the designer, the engine, the viewer). Is the font or image used by the designer on their PC, is it available on the engine, and on the viewer PC etc
Some tidbits to end.
- Behind the scenes, FGLSERVER is used for fglrun to communicate to gdc. When running via Genero Application Server, you don’t ever have to explicitly set it but FGLSERVER is also set for fglrun to talk to the proxy process. If you are wondering why FGLSERVER is set when using GAS and inside a Genero Mobile app, that is why
- Within a Genero Mobile application, a mobile app consists of an fglrun thread and a UI thread. Again fglrun process talking to UI so FGLSERVER will be set, and if you think about client-server (runOnServer) or development mode, that is effectively just using the UI thread, the fglrun is on the connected server.
- Look at GREDIR/src/bin/gviewdoc.4gl to see what is happening when you preview a report, see the completed report being moved or copied and then viewed.
- Code completion, real time syntax checking, code beautifier and even code quality, deep down that is simply an execution of fglcomp with certain arguments as you might have seen in this vim setup guide.
I appreciate I may have raised more answers than answered with this article as it is widespread. Don’t be afraid to dig deep down to the O/S level and try and understand what is happening as that may help you analyse and resolve issues, and improve your usage of our products.