Mark Phillips Phillips
Forum Replies Created
-
Bravo, Francisco!
-
Paul, let’s meet on Skype. John Boehme, like Walter Venable, has built some awesome tools. Reverse engineering an MS Access “app” seems like a good application of his tools.
-
We don’t have any problems. Our Omnis desktop connects to local postgres.
We use Postgres 9.5, moving to postgres 12.
Omnis Studio v6 and v10.1
use Host: localhost (or 127.0.0.1)
database name, user name and user password, and you should be good to go. Test logon using pgAdmin or similar. -
I removed the statement “extension”: false; from the library.json file and Omnis Studio v10.1 built a new library. With that I was able to replicate the behavior you describe. Interesting, in the wrong way. 🙂
I cannot think of a workaround at the moment, but I will consider this further in the days ahead. -
I ran the json import but it failed on an error at line 0 of library.json.
Double clicking on the error list open the Find and Replace dialog to search for “T_report_parameters”. That is, I think, simply what is in the search buffer from another project. So I don’t know why the build fails. -
I could not replicate your results, as I understand them. However, I did spend some time on the theory that you are seeing the results of a namespace collision. That is two or more instances with the same name. In my quick & dirty testing, I could not rename the window toolbar, nor the button object it contains. I was able to change the name of the toolbar in the Omnis window.
So it appears there may be a fault in the $name.$assign method for the window toolbars group. -
To follow up, the xcomp directory in the application tree, not in the app data directory created by firstrun. So, you will need a method to assert proper permission to add to the xcomp directory. FWIW, it can be done; we do it although keeping up with new rules from Apple is a challenge. If you support windows only, you may enjoy an easier time with it.
-
I don’t use AutoUpdater. I wrote a similar tool, Molu Update Server, circa 2007 that handles all update tasks except replacing the Omnis engine itself. Omnis Studio 10 has an option of running a script at launch, which promises to ease the update process.
The challenge of writing to the xcomps directory is the access permissions enforced by the operating system. I am using an iPad at the moment so I cannot verify this, but any file that is put into the “first run” target directory in the user application support area should be writable by an Omnis app or external app designed to update your application. -
we use this in Omnis Studio v6.0. “homedirectorypath” is a character variable.
For Mac,
; user home path
Do $runapplescript(‘path to home folder from user domain as string’,homedirectorypath) Returns errcode`
Calculate homedirectorypath as replaceall(homedirectorypath,kDq,”)
For Windows:
If isunicode()
Register DLL (“shfolder”,”SHGetFolderPathW”,”CJJJJCN”) Returns lnError
Call DLL (“shfolder”,”SHGetFolderPathW”,0,pnFolderType,0,0,lcString,lnError) Returns lcPath
Else
Register DLL (“shfolder”,”SHGetFolderPathA”,”CJJJJCN”) Returns lnError
Call DLL (“shfolder”,”SHGetFolderPathA”,0,pnFolderType,0,0,lcString,lnError) Returns lcPath
End If
Calculate homedirectorypath as lcPath -
Thanks to everyone who replied here and privately. I have identified a project for testing the new DML/SQL bridge in Omnis Studio 10. As we progress I will try to share what we learn here.
