I need to know the user name and other data of the logged-in user in a project organized using BPLs. That is, how and where do I need to declare the user object and its creation, and how to get access to that object when a package is loaded at runtime? I don't have enough experience working with packages.
In a regular app, for the programmer there is no difference between using runtime packages or all in a single exe
You can change the project to go with runtime packages or not, and your code won't change at all
That changes when you make a modular app that loads BPL modules on demand, chosing at runtime if a given module will be load, and doing it dynamically (ex. app made with a plugin-architecture in mind), then you need to design your own strategy to handle that
Myself, I work in that second way, and I do have some main modules wich give services to the "plugins", so when they are loaded, they do register themselves with the system: user control, navigation, whatever
There is nothing special to use objects in a package. You just add the unit name where the object is defined to the uses clause of the unit where the object is to be used.
You should really read the documentation on this topic. The you may ask more questions to clarify things you don't understand.
Related
I'm looking for a framework that will allow me to write a SPA and a embeddable library. I would love to have a way to share component between both. So I'm looking for a solution that has relatively small amount of potential conflicts with other frameworks and with AngularDart it self. Including case when library has been included using script tab, yes two versions of AngularDart on the same page. A framework that has less Global Objects, no Standard Object overrides, no Global Event handling and limited polyfill conflicts.
Dart and AngularDart seams what I need, but I also need more details and docs to validate my assumptions. Anything you are able to point out would be very helpful and greatly appreciated (issues, PR, blogs , roadmap, commits, specs, docs)
It's possible to run multiple AngularDart apps on the same page. I've tested AngularDart todo example app embedded in itself. But I need more details on what dart2js is doing and how compiler avoids global scope pollution.
Yes, AngularDart should be well suited for your requirements.
Dart itself shouldn't pollute your scope at all, you can try running dart2js on something trivial (like just print inside main) and verify the code - it creates a closure and executes it, so nothing inside is accessible from outside. There is also no patching of any global JS objects, so you can run it alongside anything without interference. If it's not the case file a bug.
You can run as many AngularDart applications on a single page as you wish. To get them fully isolated you can compile each one separately with dart2js, then they wouldn't be able to access any of each other internals whatsoever.
We are currently looking at the newest version (2.60) of NopCommerce in MVC and we will be integrating it pretty soon…We’ve downloaded the Source Code and paid the 20$ for the User Guide documentation. The documentation is great! I mean…it is great in the sense that it explains how to deploy, install and how to work around the UI Frontend and Backend. This is great for an overall overview but what it lacks is the understanding of how to work with NopCommerce as a team. What are/is the best practices etc...
As an example (or parallel), if you decide to work with Dotnetnuke as a team, you usually work in the following fashion:
Each developer downloads/installs Dotnetnuke locally on their
machine.
You also download/install Dotnetnuke on a dedicated server (let’s say
dev-server).
As a developer, you work and create modules which you test locally
within your Dotnetnuke installation.
Once it is done, you package your module (and any SQL scripts that
comes with your module) into a zip file.
Once the package is ready, you upload/install that package on the
dedicated server (dev-server).
This approach works great for Dotnetnuke and more importantly if you have a team of developers creating modules.
My question is how does a team work with NopCommerce MVC?
I’m assuming it is a bad idea to directly work within the source code in case your team decides to modify core elements/source which will make any upgrade to newer versions impossible (or break changes).
I’m not sure if my parallel to Dotnetnuke is a correct one…but would anyone have any idea (or help me clarify) how does a team work with NopCommerce MVC.
In addition, should the team only rely on creating plugins for NopCommerce and stay away from modifying the core or should this be irrelevant?
What about adding new objects in SQL (or modifying existing ones) should we prefix our objects in case an eventual NopCommerce MVC upgrade creates similar objects and/or overwrites them?
Thank you for helping me shed some light on this.
Sincerely
Vince
Plugins in NopCommerce are almost like modules in DNN. Depending on what you need to do, it sometimes is necessary to modify the core code.
What I've been doing for the Services is create a new class and inherit from the existing service, then override the function you want to change. Create a new DependencyRegistrar class and set your new service classes as the implementation for that particular interface. Also make sure the Order property is 1 so that your DR class is loaded after the stock one. Since you're inheriting from the core class, any functions you didn't override will be handled by the parent class. If I need to add a new function, I'm just modifying the interface, putting a stub in the stock class, and implementing it in my own.
Views in the Nop.Web project can be overridden by Themes. The Admin stuff and the Web Controllers get trickier. I'm just modifying those files directly.
The Core and Data classes can be done using partial classes to add your new fields.
In any case you will still need to merge changes with your solution when an update is released. My opinion is that you are better off writing clean, readable code now and bite the merge bullet when it comes.
I don't really worry about SQL scripts right now because I'm a single developer but maybe you add a folder for ALTER scripts and name them after the day they were created. Then each dev knows which scripts they need to run when they get latest.
I'm working on an ActiveX where the same code base should be used to two different ActiveXs, meaning, I have the single solution which is built from several DLLs.
When I build the solution for creating the CAB for ActiveX A, I change the DLLs class IDs to specific ones and when I built it for creating the CAB for the second ActiveX, I changed the class IDs to something else.
I need both ActiveXs to be able to run on the same machine.
Basically, it works fine except for that in certain scenarios where I run different versions of the ActiveXs (ActiveX A is from older code version than ActiveX B) there is un-desired behavior.
It looks like that ActiveX loads some DLLs from ActiveX B (which is from different code version).
Sorry for the long description but last important information, since both ActiveXs come from the same code, I have the same class name which is exposed to the javascript which calls the ActiveX.
In the registry there is total separation in all keys except for the following (NetworkInterface is the exposed class):
[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\MyActiveX.NetworkInterface\CLSID]
#="{31ED2205-F6AE-4133-AD30-60CA2783ADA6}"
When installing ActiveX I see this entry with the right class ID but when installing the second ActiveX the key is overridden by the second ActiveX.
Is it possible to achieve what I'm trying to achieve?
Is there any way to have the same class registered with different class IDs?
Thanks.
#Lior, You answered your question yourself in this phrase: "to have the same class registered with different class IDs". In fact, we are talking about ProgID's, or programmatic identifiers - MyActiveX.NetworkInterface in your case.
There is just one dedicated registry hive for ProgID's - HKEY_LOCAL_MACHINE\SOFTWARE\Classes\, and if you use a ProgID in your client code to instantiate a component, you can do it only for one ActiveX component. When you create an instance using a ProgID, the corresponding CLSID is determined using that registry hive, and the executable DLL/OCX/EXE which implements that class is used. For the latter case, the corresponding registry hive looks like this:
HKEY_CLASSES_ROOT\Wow6432Node\Clsid{6935DB93-21E8-4ccc-BEB9-9FE3C77A297A}\InProcServer32
The best thing which can be done in this case is to use two different ProgID's for your two ActiveX components. Even if you use the same source code for the main classes, you can use them "as is" in two different projects which are used to compile components with separate ProgID's. It seems, all dev environments (VB6 you're maybe using) allow you to do that.
Some more info about this can be found in this article: http://www.vbaccelerator.com/progid.htm
We had the same issue with our ActiveX components, and our experience tells us that to have different ProgID's is the best choice. Even if you release a next version, change the ProgID. This will allow both versions to coexist in the same OS without any problems, and the developers can upgrade the existing projects step-by-step.
===
As an answer to your question, I have an idea of how you can try to solve your problem if you cannot change ProgID's. As I know, you can activate ActiveX's using directly their CLSID's, and different dev environments use different techniques for that. I do not have your project, but if you use JavaScript, you can try the recipe from this article:
http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/08652e9e-7deb-40a3-8c1a-f9becdcbf56e/
In a nutshell, you do not need to create your ActiveX objects using a call like this:
myobject = new ActiveXObject("SAMPLEACTIVEX.sampleActiveXCtrl.1");
You need to put your two ActiveX controls on the page using the OBJECT tag and call the methods of your objects using their names (id's) on the webpage. If you look at an example of the HTML OBJECT tag, you'll see something like this:
As you can see, you can use the specified ID to access the members of the object you exactly need. Many examples of that are already on SO - here is one of them:
javascript: "Object doesn't support this property or method" when ActiveX object called
tldr; at bottom.
Ok, so once again an interesting problem and I'm looking for a fun and interesting solution.
My current project involves being very modular, meaning the program functionality will be easily changed based on different modules and the program would adapt.
So I started out with the typical route, which is using DLL plugins. Now this is just way to normal, I want to think outside the box a bit.
The modules included in my program are long running campaigns that may take weeks to finish, and there will be many running at a time. So stability is a big issue, so I thought about what Google Chrome does. Processes, not DLLs or threads.
So I have a framework going and I need a way to get some information about each module (which are now EXEs). Now for my DLL framework I was exporting a "Register" function that would fill in some information.
So I thought to myself, hey EXEs can export functions, let's see if that actually works...It doesn't. I did some research into how Windows handles theses things and I don't feel like hacking the PE headers on the fly (but it's the out of the box kind of thinking I'm going for).
I'm planning on using named pipes and CLI parameters to transfer data between the main program and the module exe's. I could use that in a register fashion, but I want to here other peoples thoughts.
tldr: I'm using EXE's instead of DLL's for plugins. Looking for a way to easily export one time information like a exported "Register" function would on a DLL. Thoughts?
You might still consider having the modules written as DLLs with defined entrypoints (e.g., the Register function). Then you write the executable that loads the specified DLL. Your main application would fire off the driver executable and give it a name of a plugin DLL.
That way it is still easy to define and export the set of APIs that must be provided yet still run it as a separate process. The one executable that you write can load the specified DLL and then handle the necessary IPC with the main app.
You could define a protocol via the stdin/stdout, named pipes, sockets, etc.
I have successfully used 'plain' COM for several projects, and objects inheriting from TAutoObject. The bonusses here are IDL; the interopability with .Net, VBA and other non-Delphi things; and the fact that implementors still can choose wether to supply a DLL, an exe, an NT-service, and optionally run hosted over the network (COM+/DCOM). There may be several considerations you should handle about multi-threading and locking, but I found all that I needed to know online.
You can, of course, not use symbols exported by a (running) exe since it is running in another boundary. But, you can load an exe as an image (as you would do with a library) using LoadLibrary(Ex) and then, use the functions exported by the exe. I have tested (just for fun) when debugging PeStudio. See the snapshot below of chrome.exe loaded in the process space of PeStudio.exe using LoadLibrary.
I need to make an app that will let users select some options, click a button, and a separate compiled app is created. Is this possible? I am using delphi 7 and 2010.
Thanks for the replies. Here is a little more info.
It would have to be a graphical app and create a graphical app.
What I want is the user to fire up 'App A' (I originally made), be able to select some options (I apologize for the secrecy. I think this is a million dollar idea that probably 3 people may find useful :) then use the program to create 'App B.' 'App B' can then be distributed to end users and 'App B' is a single executable that includes a compiled app plus the configuration data. I don't care how, but I need 'App B' to be a single executable.
I wouldn't even need to use Delphi for the final compiled app. If there is some sort of "pseudo-compiler" that I can call from Delphi that would marry a precompiled exe and a separate config file into a single executable. That would work just fine as well.
Thank you for the replies and help.
Thank you.
I also faced a similar situation once. I had to produce an exe using my exe. I didn't want to go the compiling a source code because of complexity and license problems.
Lets call the parent app P and child app C. Also lets assume that whatever option C needs can be summed up in a config file (XML/INI etc). What I ended-up doing was:
Create P and C. Inserted C in resource data of P.
When user clicked the button after selecting options, P would extract C from its resource data.
Created an XML file containing the options selected by user and inserted it in C's resource data.
So whenever C will run, it will use the options given in the XML file stuffed in it. It looks like complicated and hacky but is reliable and simple. Do a google on "delphi embedding resource in exe" and you will find plenty of articles to do above.
It is possible. You will need a Delphi 7 (or compatible) compiler (command line at least) on the target machine. You will also need all the source code for the compiled application and that includes all the third party libraries if you use any.
When you have it all set just call the command line compiler (DCC32.EXE) with the proper parameters and paths.
You can use two approaches for this:
Call ShellExecute
Call CreateProcess
You will have more control over the execution with CreateProcess. Also you will have to watch out for legal issues and licences if you plan to use the compiler this way.
Given that the Delphi compiler can't be redistributed, one solution if the user has not a copy of Delphi may be to use a script engine (i.e. RemObjects PascalScript, but there are others), generate code for it, and embed that code (i.e. within a resource) in an executable that will execute it when launched.
Create a separate stub executable that implements all the logic you need, and that reads its configuration from its own local resources (look at the TResourceStream class to help you load a resource at runtime).
Include that stub executable as an RCDATA resource in your main app's resources when it is compiled.
At runtime, the main app can extract the stub executable from its resources when needed, save it to disk, and insert the necessary configuration data into the stub's resources using the Win32 API UpdateResource() function.
Without knowing more about why you think you need to do this, I assume you don't actually need to do this. Given the stated requirements, I'd simply have one app, written in Delphi, that looks for the existence of configuration data (.ini file, registry, etc..) In the absence of this, it presents a screen that "will let users select some options, click a button". Then the options are stored in a .ini file, and the rest of the program proceeds, making use of those options.
Alternately, I'd use some pascal scripting, such as provided by TMS.
If you are looking for a way to crank out custom-branded versions of an app, maybe use Inno Setup with a ResHacker step. i.e. gather requirements in Inno, spit out your .exe into a temp directory, use ResHacker to modify the .exe, copy it into the program folder.