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
Related
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.
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.
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.
(This might be better in the TestComplete forums, but I thought I'd give it a shot here anyway)
We are looking in to automated testing of our Delphi 2010 application with TestComplete. The main control that our application uses is our own custom control that derives directly from TCustomControl.
(For reference the control is like a digraming tool that display boxes with text in them. These boxes can be selected. the control is completely custom drawn, including the selection).
We are looking in to making this more TestComplete friendly so we can read data out of it (e.g. what data is loaded in to the control, what data is selected)
I should also mention that our application uses an MVC architecture and makes heavy use of interfaces. TestCompletes debug agent can't seem to return any type information about interfaces and thus we can't get any data from them. I suspect this is the root of our problem
I'm considering these two approaches:
Add new properties to the control that will return information about the currently selected box(es). e.g. text in the box, position on screen, hierarchical path, and access them via TestCompletes debug agent.
Look at creating a custom control add on for TestComplete (I'm not even sure you can do this with Delphi controls)
The problem with the first approach is the linker will often elimate properties and functions if they are not being used. We want to use our release build for testing not a debug build.
Does anyone have any advice on this or experience with this type of thing?
Thanks
Edit: I've just read the SDK help and custom control addons can only be created for .net and WPF controls.
You are right about the debug info - you can strip it out from the release build. Thus, you will test a release build and have access to internals at the same time.
A note regarding this situation: "the linker will often elimate properties and functions if they are not being used." You can cheat here to make the linker generate debug info for those funcitons:
Make the funcitons published. The linker does not touch published elements.
Make the funcitons virtual. The linker does not exclude virtual methods.
Call your functions somewhere in your code. To include the call in your code without actually calling anything, you can do something like this:
var t: Boolean;
begin
t := False;
if t = True then
TheFunctionThatNeverExecutes();
...
end;
You should reconsider your decision to use the release build for testing. The reason is that TestComplete needs some magic to make your testing life easier while you don't want this magic be present in the release build. So if you can elaborate on the reasons for not using a debug build for testing, we can try to find a solution to revoke this decision. The result may be that you will have access to all the relevant data of your control if you only reveal all available power of TestComplete.
Now back to the original question: You can overcome the interfaces problem by creating some special classes that wrap those interfaces and thus make the properties available in TestComplete.
Create a small (perhaps invisible) test form where you centralize access to instances of these classes. (Now the release mode link) Only create this form in debug mode so, when carefully designed, you only link in the relevant code when needed for testing.