Hi,
It is possible to query the registry to look for the installed version of Office (Office 9/10/11/12 etc) and then to create a dynamic external user object to support the ActiveX interface to this (ExtLibSource.Create()) filling in the attributes from the registry information.
Once you have this ExtLibSource you can compile (i.e. Parent it to your application) at runtime and then make another source object to interact with it.
So if your ExtLibSource office object is always called MSOffice you can make a new dynamic ghost frame (so you can catch events) source object called ‘MSOfficeX’ referencing MSOffice by:
· Using stored strings in the your code or in your database to make the script
· Using an include script (the image which contains this include script will need to be built as a library (-l))
o this is what I have seen done
Once you have built and parented MSOfficeX to you application this can be called by making by name calls using the callframe :MSOfficeX_Name() type syntax.
I understand that between different versions of MSOffice that there are differences in how it needs to be driven, you will need to embed the solution in this for MSOfficeX either by having multiple include scripts to cover the different versions of Office or if you are a 3GL freak you could use macro variable language in a single include script to customise the MSOfficeX script before it is compiled.
I didn’t implement this I am just working from memory of 14 years watching it evolve…
We are all happy to help you along while you get this working, just ask questions when you get stuck.
Good luck,
Adrian
--
You received this message because you are subscribed to the Google Groups
"OpenROAD Users Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to openroad-user...@googlegroups.com.
To post to this group, send email to openroa...@googlegroups.com.
Visit this group at http://groups.google.com/group/openroad-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/openroad-users/65a9d610-9071-4622-9547-db350d53faba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi,
The registry can be queried by creating 3GL procedures in OpenROAD to access the advapi32.dll.
You need to look up procedures in this library like:
regopenkeya
regclosekey
regenumvaluea
regqueryvalueexa
Also when I said ‘callframe :MSOfficeX_Name() type syntax’
I forgot to mention that MSOfficeX_Name is a varchar(32) with the value ‘msofficex’ to match your new ghost frame.
Cheers
Adrian
To view this discussion on the web visit https://groups.google.com/d/msgid/openroad-users/012f01d100ce%2450a04a00%24f1e0de00%24%40demon.co.uk.
Attached is the export file of a sample application, which does it:
The 4GL Procedure “createExcelLib” scans the registry (using the undocumented REGISTRYKEY class) and creates an External Class Library “MSExcel” according to the version found.
The IncludeScript “top_script” contains the code you would usually use in the frame script (if you have MSExcel defined in your application).
The frame “top” is the frame which does the Excel connection when pressing a button.
The starting procedure “starter” calls “createExcelLib”, fetches the CompSource of frame “top” and of the IncludeScript “top_script”,
then sets the Script of the frame “top” to the one in the IncludeScript, which contains the “MSExcel” library references.
Then the frame is called after setting IsStale=TRUE to force recompilation.
This “detour” is required as the script wouldn’t compile in the frame at development time due to the missing “MSExcel” library.
When building an image file of the application you’ll have to use the “-l” (Library) flag, otherwise the IncludeScript wouldn’t be contained in the image.
HTH.
Regards,
Bodo.
--
Bodo Bergmann
Senior Software Engineer
Actian | Engineering
Phone: +49.6103.3033.734
GESELLSCHAFTSANGABEN: Geschäftsführer: Steven R. Springsteel, Stephen Mark Padgett, Markus Bockle
Sitz der Gesellschaft: Hamburg| Handelsregister: Amtsgericht Hamburg | HRB 135991| USt-IdNr: DE252449897
--
To post to this group, send email to openro...@googlegroups.com.
To post to this group, send email to openro...@googlegroups.com.
Then just don’t call it there – this is just an example.
After changing the FrameSource of the frame (setting Script and IsStale attributes),
the frame will automatically be compiled whenever it is called the first time (later).
To post to this group, send email to openroa...@googlegroups.com.
Visit this group at http://groups.google.com/group/openroad-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/openroad-users/07884625-7250-4a93-93ab-20b8c9d7d7cc%40googlegroups.com.
Is this still relevant, because the next mail I received from you said “Thank you so much sir.... it works...”?
To post to this group, send email to openroa...@googlegroups.com.
Visit this group at http://groups.google.com/group/openroad-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/openroad-users/24b1301a-9026-4507-bd7c-a783f98a8642%40googlegroups.com.
The frame “top” is just an example name, it does not have to be the first frame in your application,
I could have called it “someframe”.
If your second (or any other) frame in the application contains the references to MSExcel,
then you will need to do the following steps for the according frame(s):
- Fetch the FrameSource
- Set its Script (e.g. using an IncludeScript, but can also come from somewhere else)
- Set its IsStale to TRUE
To post to this group, send email to openroa...@googlegroups.com.
Visit this group at http://groups.google.com/group/openroad-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/openroad-users/8ece2fc4-c2a0-4860-a832-fae8c2c98fba%40googlegroups.com.
Ok, with multiple versions under the key there is a problem.
You could loop through all the subkeys of the HKEY_CLASSES_ROOT\TypeLib\{00020813-0000-0000-C000-000000000046} node, e.g.:
FOR i=0 TO rk_excel_typelib.NumSubkeys-1 DO
so_version = rk_excel_typelib.EnumKey(keyindex=i);
…
ENDFOR;
But even then you would not know which is the current one – a higher version does not mean that this is the current one.
It might have been installed once, and later uninstalled, but the registry entry still remained. See for example here:
So, the only way I see is a case statement for the current version of Excel.Application class.
Example – change the script for the createExcelLib procedure to the following – you will have to add code for the other Excel versions:
PROCEDURE createExcelLib()=
DECLARE
excelExtLibSource = ExtLibSource;
rk_root = REGISTRYKEY;
rk_excel_app_curver = REGISTRYKEY DEFAULT NULL;
so_subkey = StringObject;
so_version = StringObject DEFAULT NULL;
ENDDECLARE
BEGIN
rk_root.Initialize(HKEY_CLASSES_ROOT);
so_subkey.Value = 'Excel.Application\CurVer';
rk_excel_app_curver = rk_root.Open(subkey=so_subkey);
IF rk_excel_app_curver IS NULL THEN
MESSAGE 'HKEY_CLASSES_ROOT\Excel.Application\CurVer not found.';
RETURN ER_FAIL;
ENDIF;
so_version = rk_excel_app_curver.GetValue();
IF so_version IS NULL THEN
MESSAGE 'No value for HKEY_CLASSES_ROOT\Excel.Application\CurVer';
RETURN ER_FAIL;
ENDIF;
excelExtLibSource.Name = 'MSExcel';
excelExtLibSource.UniqueId = '{00020813-0000-0000-C000-000000000046}'; // for Excel
CASE so_version.Value OF
'Excel.Application.15' :
{
excelExtLibSource.majorVersion = 1;
excelExtLibSource.minorVersion = 8;
}
// TODO: Do the same block for other Excel versions
DEFAULT:
{
MESSAGE 'Unknown Excel.Application version: ' + so_version.Value;
}
ENDCASE;
excelExtLibSource.ParentApplication = CurProcedure.ObjectSource.ParentApplication;
RETURN ER_OK;
END
HTH.
Regards,
Bodo.
To post to this group, send email to openroa...@googlegroups.com.
Visit this group at http://groups.google.com/group/openroad-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/openroad-users/3405f120-2fbc-4d80-8b43-03c3c72b41dd%40googlegroups.com.
Create an additional 4GL procedure to dynamically create an MSWord external class library,
the same way as for MSExcel (just with different TypeLib IDs, version numbers, etc.),
then also call it from the starter procedure.
Alternatively you could extend the existing procedure (and probably rename it).
From: openroa...@googlegroups.com [mailto:openroa...@googlegroups.com]
On Behalf Of EJ-Boy Perez
Sent: Freitag, 9. Oktober 2015 07:03
To: OpenROAD Users Mailing List <openroa...@googlegroups.com>
Cc: adr...@octavo2.demon.co.uk
Subject: Re: [openroad-users] Dynamic Library
Sir:
To view this discussion on the web visit https://groups.google.com/d/msgid/openroad-users/744d2c2c-568b-40a6-8ef6-b780fae43c6a%40googlegroups.com.