Comments by SheepSpeech (Top 21 by date)

And the database will be fully embedded? (The client machines won't need Access ?)

Thanks, but this link was in my original post, and I explained that I couldn't find what I wanted on that page (either because it's not here or because I don't search correctly): a System.Data.SQLite.dll working as a single file. And this is possible: I gave you a link to a tutorial with such a file.

Which page should I look to find x64 and x86 versions of System.Data.SQLite.dll ?

Which one?

Well, I found in a tutorial (https://blog.tigrangasparian.com/2012/02/09/getting-started-with-sqlite-in-c-part-one/) a single System.Data.SQLite.dll file for x86, but I can't find it in the download page (it's always referencing other dll like SQLite.Interop.dll). I would like only 1 dll as I had with this tutorial, but from the official website.

Here it is:
I have the following questions:
- where can I find x64 and x86 versions of System.Data.SQLite.dll ?
- how can I compile them myself from source code?
- is there an easy way to have the System.Data.SQLite.dll file as an embedded resource, so I'll only have to distribute one dll in the end ?

This is not what I am asking for, I would like to have one dll for x64 and then create a x64 version of my library, and in an other projet, a dll for x86 and then create a x86 version of my library.

This is what I understand:

"One is set a breakpoint in your code where you invoke functions from the DLL and then step into the code that it calls." You need to have the main app's source code for this.

"The second is to set a breakpoint inside the functions of the DLL and then run the program until one of those breakpoints is hit." You need to be able to run the debugguer from the DLL, to do this you have to attach the DLL to the app, but as I explained the app doesn't launch it in this case because it's not in its Plugins directory. If you also put the .dll in its Plugins directory and choose to launch it from the app, breakpoints are ignored.

Did you try this without the main app's source code? Thanks.

Hi,

I think it is what I've done (did I forget something? May be the .pdb files but I wasn't explicitly blocked without it).
The problem is more into this: my app loads plugins from its "Plugins" directory and then the user can choose one of them and launch it. So only attaching my extension to the app do not allow me to see the plugin in my app. Moreover, doing this way, my app doesn't load any plugin (usually, it loads all the plugins available in its "Plugins" directory).

Hello,

I have another question: in what kind of situation this ID issue may happen? Because I had this problem when I tried to create a window from a template ID, ie this way:

CDialog myDlg(IDD_DIALOG1);
myDlg.DoModal();

But I don't have it anymore if I create my window via a class, this way:

PluginDialog dlg;
dlg.DoModal();

Is it chance, or in this case there is no way I can get an ID conflict? I need some explanations.

Thanks!

I need a piece of advice:
I just want to test something on my extension's dialog, so I would like to quickly change the _APS_NEXT_*_VALUE. However, when I do that, my dialog doesn't appear anymore + its ID is not changed in resource.h. What am I supposed to do?
And also, _APS_NEXT_*_VALUE is the next value for the current project, it's a lower limit, right?

Thank you, I'm gonna try that and give you a feedback !

Hi,

Thanks for your reply. I assume the resources will simply increment by one each time one is added to the project.

However, my final purpose is to let other people create MFC extension DLL for my app. I would like to find a solution which avoid any conflict (and avoid the need to set a range), because people won't know the range used by the main app and other extensions.