|
It does not need to replace the collection. It will need to make changes to the collection in vb.net and have those changes reflected in the vb6 collection.
|
|
|
|
|
Then you don't need ByRef.
Non-value types, like your collection, are always passed by reference anyway. You're not getting a copy of the collection.
|
|
|
|
|
Thanks for your help. I was able to get it working as you described.
|
|
|
|
|
Only if the type is known in both environments.
Enjoy[^]
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Hello !
I have a visual basic 2013 application , created with Devexpress controls. The problem is that when I open each form there is a long delay.
Is there any way to pre-load the devepress dll files before the program is open , for example on my first form which is a login form ?
Thank you in advance !
|
|
|
|
|
In general, no, there isn't.
If there's a long delay opeing forms, my first question would be how many controls are on these forms?? The larger the number of controls, the longer it takes to build an instance of the form.
|
|
|
|
|
Thank you !
But if I create a standart Windows Form with Visual studio standart controls (the same number of controls) , there's no delay.
I found this article , but I don't know how to use-it :
http://www.codeproject.com/Articles/31316/Pre-compile-pre-JIT-your-assembly-on-the-fly-or-tr
where should I put and how can I call ?
thank you !
|
|
|
|
|
That's not going to do what you think it's going it.
Your problem, as I think you put it, is that every time you try to open the same form it takes forever. That means the code has already compiled into native assemblies and cannot be sped up any more.
It sounds as though you need to talk to DevExpress support on this problem.
|
|
|
|
|
Thank you !
Maybe I was not very clear.
Only the first time when I open the form there's a delay.The second time it's ok.
But everytime I open a new form for the first time there's delay.
so , how can I use the code on the article ?
Thank you !
|
|
|
|
|
Forget the code in the article.
All you need to do to get the same effect, to try this out, is NGEN. Open up a Developer Command Prompt (under Start -> Microsoft Visual Studio 20xx - Visual Studio Tools - Developer Command Prompt). The command line will be something like this:
ngen install C:\somepath\myexecutable.exe
Once that's done, launch your .EXE and see what happens.
If you're still having the problem, contact DevExpress about it. It's their controls you're using.
|
|
|
|
|
Hello !
But in my scenario the installation doesn't allow me to process the application with NGEN
So I'm thinking to use some code inside my application.
If you can explain to me how to use the code , this will be a great help for me.
Anyway , Thank you !
|
|
|
|
|
DID IT WORK ON YOUR MACHINE?!?!?!
We're nowhere near making a installation package for your application yet! We're testing a problem here!
|
|
|
|
|
Yes.
It's working on my machine
|
|
|
|
|
After you NGEN'd the resulting .EXE?? Did the problem go away entirely??
You ran the NGEN command line on your resulting .EXE, then you launched that .EXE file. You DID NOT LAUNCH IT FROM INSIDE Visual Studio! Correct??
|
|
|
|
|
|
OK, then it's easy. When you package your application for distribution, you can use something like InstallShield 2012 or better, on your .NET assembly Components, check the box that says ".NET Precompile Assembly". Done.
Why do you think you can't use NGEN??
Doing what that article says is the pain in the ass away to do it and, unless you know what you're doing, you can easily miss assemblies in your application. That methods is showing you how to do it for one assembly, not ALL of your application assemblies.
|
|
|
|
|
I read that using NGEN depend on target machine , and we should use the NGEN on every machine ???
This is what I have found :
"The idea behind NGen is that when your application is installed on the target machine, the JIT is triggered to compile our entire set of managed assemblies, and generate a native image for the application. Afterwards, when the application is launched, the CLR will make sure to load the correct native image from the disk, and so avoid unnecessary jitting
The problem with NGen is that it's quite complicated to use, and if we are really looking to avoid performance penalties during our application&'s initialization, we will have to spend more of our valuable time in order to register our assemblies in the GAC, correctly set our DLL's base addresses in order to avoid rebasing, etc"
it's correct or I read the wrong article ?
And as alternative to the previous code , I have found another code that load all the assemblies , but again I don't know how to use it :
public static void ForceLoadAll(Assembly assembly)
{
ForceLoadAll(assembly, new HashSet());
}
private static void ForceLoadAll(Assembly assembly,
HashSet loadedAssmblies)
{
bool alreadyLoaded = !loadedAssmblies.Add(assembly);
if (alreadyLoaded)
return;
AssemblyName[] refrencedAssemblies =
assembly.GetReferencedAssemblies();
foreach (AssemblyName curAssemblyName in refrencedAssemblies)
{
Assembly nextAssembly = Assembly.Load(curAssemblyName);
if (nextAssembly.GlobalAssemblyCache)
continue;
ForceLoadAll(nextAssembly, loadedAssmblies);
}
}
Thank you !
|
|
|
|
|
Yeah, you read the wrong article.
The command line for NGEN is simple:
C:\Windows\Microsoft.NET\platform\frameworkVersion\NGEN.EXE /install myexecutable.exe
Really? How hard was that?
You run it for each executable and .DLL in your application.
Now, if you set the option in the component in your installer, you don't have to worry about the command line at all. The installer does it for you!
|
|
|
|
|
Thank you !
I understand that the only existing option for you is NGEN.
Anyway thank you !
|
|
|
|
|
No, it's the option that works in 99% of cases.
I don't know about you, but I do my JIT'ing once, at install time, not on every launch of my code.
|
|
|
|
|
Ok but a normal exe file ( without using NGEN ) do JIT'ing on first start of a form with these controls ( but on every time I use the application ) .Now I want to use a code that do this process on every time that I use the application , but on a fixed point of execution ( for example on login page) and not when the forms are open.
Anyway , this is only my opinion. But it's so difficult for you to show me a way how to use the code for doing this process. I want just to try both the alternatives.
Thank you !
|
|
|
|
|
alejx wrote: Ok but a normal exe file ( without using NGEN ) do JIT'ing on first start of a form with these controls ( but on every time I use the application )
No, it doesn't. The JIT happens once, the first time the code is executed. A native image is generated and put into the native image cache.
When you run the code from inside Visual Studio, that native image only lasts for the one time you run the project. When you run the project again, a new .EXE is generated and new native images are generated as the code is executed. This happens every time you run the project from inside Visual Studio.
alejx wrote: But it's so difficult for you to show me a way how to use the code for doing this process. I want just to try both the alternatives.
The reason I don't recommend do it that way is because if you don't understand the code and why it works you can't support it in the future. What if the code no longer does what you assume it's should be doing anymore? What are you going to do then??
That's why I don't recommend you use it.
|
|
|
|
|
Ok I try to use NGEN.
But I have a last question ( that maybe has nothing to do with this case but maybe yes ).
I'm thinking to use a code protection software , (like .Net Reactor) to protect my job.
This software implement these protections to exe file :
NecroBit Protection
Native Code generation
Obfuscation
Control Flow Obfuscation
String Encryption
Anti Tampering
Resource Encryption and Compression
Dependency Merging
Now , if I protect the .exe file , after is possible to use NGEN ?
Thank you !
|
|
|
|
|
You're going to have to ask the provider of the software you're going to use.
But, in general, yes, you can use NGEN with obfuscators.
|
|
|
|
|
If I were in your shoes, this is what I would try:
Put some of the DevExpress controls onto the Login form, but make them invisible. This will force them to load, and hopefully your other forms will be much snappier.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
