Hi,
I have the need to use a ddl from one app inside another app. Both apps use MSSQL driver.
So I have App A(dctA) ->dll 1,2,3->data dll A
App B(dctB) ->dll 4,5,6->data dll B
I would like to call for example a procedure inside dll 4 from App A frame.
The App A referencing dll 4 compiles but when it starts it keeps asking me for sql login, even if the variable is set, but then after if I insert manually the sql login parameters the application crashes in clarun, clamssql
Is it possible to achieve what I want or the only way is to have one dictionary and one data dll?
Thanks
I assume you are using ABC? I suspect you are running into the need for each ABC Data (DCT) DLL to be initialized, actually all the ABC DLLs need to run the ABC DLL Init code.
On GitHub I created the below example of Legacy and ABC coexisting. The SchoolBoth folder would be the project of interest here.
What this required was 2 Data DLLs one Legacy and one ABC. The Legacy APP was primary and it provided the frame. I needed the Legacy frame to run the ABC DLL Inits. I did this by making the Hand Coded ABC Init DLL that gets called by the frame that has this code:
Abc_Init_Kill PROCEDURE(BYTE KillMe=0)
CODE
Message('Abc_Init_Kill v2 KillMe=' & KillMe)
IF ~KillMe AND ~AbcHasBeenInited THEN
GlobalErrors.Init(GlobalErrorStatus)
FuzzyMatcher.Init ! Initilaize the browse 'fuzzy matcher'
FuzzyMatcher.SetOption(MatchOption:NoCase, 1) ! Configure case matching
FuzzyMatcher.SetOption(MatchOption:WordOnly, 0) ! Configure 'word only' matching
INIMgr.Init('.\AbcInitExe.INI', NVD_INI) ! Configure INIManager to use INI file
DataAbc:Init(GlobalErrors, INIMgr) ! Initialise dll (ABC)
ProcABC:Init(GlobalErrors, INIMgr) ! Initialise dll (ABC)
AbcHasBeenInited=1
ELSIF KillMe AND AbcHasBeenInited
AbcHasBeenInited=0
INIMgr.Update
DataAbc:Kill() ! Kill dll (ABC)
ProcABC:Kill() ! Kill dll (ABC)
INIMgr.Kill ! Destroy INI manager
FuzzyMatcher.Kill ! Destroy fuzzy matcher
END
RETURN
I think you need to make a similar ABC Init DLL for your App B chain. I made my ABC Init DLL by making an EXE APP with just the ABC frame (AbcInitExe.cwproj) that linked in the DLLs, then copied the generated code into my hand code project AbcIniDLL.cwproj
Thanks for detailed answer.
Yes I was thinking about dct init procedures, but what made me think it is impossible is that after I inserted the sql login the app crashed. It might be something specific to the mssql driver. Which driver you have used in legacy and abc data dlls?
The thing is that the abc init procedures are called really, since both apps are abc and so for what concerns the App A the dll 4 is just another dll, and it does as for the others.
How is your connection string declared?
Do you use a global variable declared in the DCTs and if so are the 2 global variables exactly the same?
We have 10 functional modules each with their own DCT and data DLL and we call procedures in one functional module from another functional module and it all works.
In our case we’re using the Clarion (AKA Legacy) template chain with the same SQL_GLO:Owner string declared in every DCT
I suspect you might have huge problems with the ABC Class declarations from each Dll stomping on the other. There would also be the problem of globals that exist in both, and are looked at locally to that dll.
I’m not sure you can do this.
No, I do not have compilation problems.
This is interesting.
Yes I use the same global variable but I came up with the following solution.
Create common dll that will hold just a global non threaded variable for the owner.
All other dll’s reference this.
The first app that starts sets this variable.
All the procedures, in every module, that I know will be first in thread read this variable and sets the real owner variable.
I am not sure on the following.
If data dll A and B both exposes ownerVariable X, same name, and when bulding dll 4 references data dll B and dll1 references data dll A, when starting the A app, the dll 4 will still reference ownerX from data dll B, because it was specified so when data dll 4 was compiled.
I mean, I know there is something as late linking, but I encountered this years ago in embedded developing not in windows.
Anyway this is interesting. Are you using mssql driver?
Yes we’re using the MSSQL driver as well.
It all seems magical but Clarion sorts it out somehow 
We’ve had instances in the past where developers have called procedures in a DLL and specified the wrong DLL name, but Clarion even sorts that out as long as the DLL is referenced somewhere in the APP
ok, thanks, then another round if investigation is needed
One of the advantages of my datafier class that I wrote about in Clarionmag, was that you didn’t have to worry about who owns what variable. OTOH, it did require a global class. But that’s it. Then you could save/retrieve as many “global” values as you wanted, from any app, without having to compile any other app unless they have a specific need for this value for something.
https://clarionmag.jira.com/wiki/download/attachments/399448/cmag-2009-01.zip?api=v2
https://clarionmag.jira.com/wiki/download/attachments/399448/cmag-2009-01.pdf?api=v2
Interesting concept, but I do not think it can help with my MSSQL/ two data dlls problem I think
I had something similar with one EXE that worked with 2 DLL “chains” each with its own DCT Data DLL. I also ended up making a common data DLL used by both for some exported data variables that had to be shared by both.
I did these 2 DLL chains because the changes needed for the “new system” were major, and I needed the old code to still work the same for 3 years. To make the code work both ways seemed too risky. So I copied all APPs and started building the new system.
One discovery is you CANNOT have 2 APPs with the same name even though they build different target DLL names. The APP Name is used to name Resources in the DLL like Windows are a resource in DABDUMP. If 2 APPs have the same App File Name then the RTL gets confused and loads the wrong Window Resource. I would see the new Windows in my old code. I had to rename all the “new system” APPs.
I don’t know if this will apply to your case, but maybe helps so here it goes…
I have made changes to the shipping templates (I am today or tomorrow posting them to softvelocity’s problemtracker) to allow creating an APP which is a DATA-DLL (that is, declares FILEs and creates and exports FileManagers and RelationManages) but does not link ABCs.
I use this to have an application that links in DATA-DLLs from two different dictionaries, and have used this for a few years in Clarion 6 now. I ported this to Clarion11 and as far as I can test it works as expected.
I have a demo application that has 3 apps:
1 - DctA data-dll with ABC linked in.
2 - DctB data-dll with ABC external (gets them from first DLL), and
3 - An EXE which calls procedures from both DctA_data_dll and DctB_data_dll.
The limitation of course is that you can’t use files from both dictionaries in a Clarion browse as the APP designer doesn’t allow it.
Let me know if this would be of help and I’ll send the template changes. BTW, these changes have no impact on existing clarion applications. They only allow you to make an APP where ABCs are external but FILEs and FileManagers/RelationManages are internal and exported. Something the shipping templates should allow but currently don’t.
I tried to post this to clarion’s problemtracker but for some reason can’t create new entries… Nevermind this… I was able to post the report and template changes. Hopefully other people will want this and ask softvelocity to include the changes… Does not affect existing code and allows to do something helpful (I think).
In your PTTS 43222 you say you " get errors at compile time " but never list the exact error messages?
You say " I am including the required changes to allow to do this " but there is no attachment?
You can edit your report and add Additional Information to describe the errors plus attach zip files.
Your best chance of it being fixed will be if you attach a simple example that can demonstrate the problem. You can use an example like the DLL Tutor to make one.
Hi, thanks. I thought I had attached the template changes and example apps, but they didn’t get included.
For some reason I can’t attach files, I get an error “Your insert failed” " Build No: : Must be in file".
I have tried selecting a different build number but that doesn’t work.
Tomorrow I will add an example that shows the error that you get when you try to have a DLL that exports all files but declares ABCs as external. With the shipping templates you can’t do that. You get errors with respect to the files. The template prompts allow you to set it up that way, but the template system doesn’t process it correctly.
I will then try to send the attachment again.
Edgard
Ok, thanks but it would not solve my problem. I have moved forward and changed the approach. Thanks anyway