|
Hi,
if your values are unique, you can add a inverse hash table to the normal hash table,
where you add (value,key) instead of (key,value).
|
|
|
|
|
|
Hi all,
I am currently downloading the "Microsoft® Windows® Software Development Kit for Windows Vista™ and .NET Framework 3.0 Runtime Components". It's a huge 1.15GB download.
What I want to know is: can I still use Visual Studio 2005 to work with .NET 3.0 or do I have to install a special module? I have Windows XP Professional with SP2. I suppose that everything needed to work with .NET 3.0 is included somewhere in those 1.15GB
Any special stuff I need to be aware of to jump from 2.0 to 3.0?
Any insight is greatly appreciated.
Thanks,
Talal
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
--Rich Cook
|
|
|
|
|
Talal Sultan wrote: Microsoft® Windows® Software Development Kit for Windows Vista™ and .NET Framework 3.0 Runtime Components
As the name suggests, the Windows SDK is meant for Vista. You can install .NET 3.0 on XP though. Note however that runtime components are not for development, for that you need to install additional components (like WF extensions for VS etc.).
Talal Sultan wrote: Any special stuff I need to be aware of to jump from 2.0 to 3.0?
A somewhat common misunderstanding. You don't jump from 2.0 to 3.0. The name is misleading - 3.0 is basically still 2.0, but with some enhancements (WF, WCF, WPF, Cardspace). So learning these technologies will get you teh knowledge of .NET 3.0.
|
|
|
|
|
Thanks for the clarifications. True, I have heard that 3.0 is not really a new framework but just the 2.0 plus some new things in it. As I have read, it was called WinFX but was renamed to 3.0, which, personally, I think is not a good idea 
So if I got it right, these enhancements need the equivalent modules in VS 2005 so that I be able to program with them, right? You said that there are WF extensions for VS which are, of course, for the WF enhancement you mentionned later; so I am assuming that there are also WCF extensions for VS and WPF and Cardspace. Is is a right assumption?
I'll check the download I got and see if those extensions are already available in it.
Thanks again
Cheers,
Talal
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
--Rich Cook
|
|
|
|
|
|
szukuro wrote: The name is misleading - 3.0 is basically still 2.0, but with some enhancements
...and to think that WinFX was renamed to .NET 3.0 in order to "reduce confusion"
Kevin
|
|
|
|
|
|
Hello. I am designing an application that will make use of plugins (.net assemblies loaded at runtime containing classes implemented from a common interface). The issue is, i would like to be able to put these DLLs in a folder other than the application's folder, so it could be in a folder like \Plugins\ or something. It works fine sometimes, the problem is that when a plugin references a local assembly, it tries to find it in the application's folder and not the plugin's folder. For instance, if one of the plugins is loading XLS files and I have an XLS file reader class in a seperate assembly along with the plugin, I will get an error since the application is trying to load the assembly from its location and not the plugin's location. Is there any way to get around this without dumping my assemblies in the GAC?
-- Steven Hunt
|
|
|
|
|
Hi Steven,
I'm assuming that the Plugins folder is a subdirectory of the executable's folder. In that case, you should be able to use the Probing element in the app.config file to have the runtime look for assemblies in that folder.
Also, you can read up on the whole process: How the Runtime Locates Assemblies
Hope that helps,
Eugene
|
|
|
|
|
Thanks for the help. I also discovered Assembly.LoadFrom(string location), which also looks promising.
-- Steven Hunt
|
|
|
|
|
I have an issue with my MDI application. When I drag my MDI child form outside the MDI Parent client area, scroll bars appear on the MDI parent form. How can i get rid of these scroll bars.(what we really want is, that scroll bars should never appear on the MDI Parent form), setting AutoScroll = false; HScroll = false; VScroll = false; does'nt work, scroll bars still appear.
The default Windows behaviour for MDI applications is that they never have scroll bars on MDI Parent.
thanks,
|
|
|
|
|
sarah_malik wrote: The default Windows behaviour for MDI applications is that they never have scroll bars on MDI Parent
Obviously, this is an incorrect assumption since you're not using a Win32 control.
The MDI Child forms get rendered by a hidden, but in plain sight, control on the MDI Parent form. This is the MdiClient control. There is no property or method to turn off the scroll bars in the MdiClient control.
What you were changing were the properties of the MdiParent form, not the MdiClient control.
Every method I can think of for customizing the MdiClient control requires you to create your own version of the control, or process the window messages going to the control and alter them to keep the child windows from exceeding the boundries of the display area.
Dave Kreskowiak
Microsoft MVP
Visual Developer - Visual Basic
2006, 2007
|
|
|
|
|
Thanks Dave
|
|
|
|
|
I have an add-in to PowerPoint 2007. This addin is developed using .net framework 2.0. Its working fine on my machine with VS 2005 installed. If I deployed on the client machine which contains only Office 2007 but no .net framework 2.0 installed. Initially, it checks for pre-requisites(.Net 2.0 framework, shared addin extensibility (KB908002), Shared Addin Support Update for MS .Net Framwork (KB908002)) and install the addin successfully. The addin ribbon control is not displayed.
Please suggest me how to trouble shoot this?
Is it any particular main dlls to ensure all the dlls are installed in registry.
|
|
|
|
|
Hi,
Can someone please help me out here.
I need to display some columns which are part of the table and some which are not, in the crystal report.
For eg. From backend i am getting columns like call_Date, sum(p1calls) as "call_total". and i am taking it in the dataset.
i could display "call_date" by just dragging that table column on the report. Now i need to display "call_total" which is not actually a database table column but that is sum(p1calls)(This is not a single value but there is a value in each of the rows).
So, Can someone please tell me how to display this column on report.
Thanks & Regards,
Prash
|
|
|
|
|
Hi,
I have a form that takes a number from the user and loops through this number to do some calculations and database access:
for (int i=0; i <NUM; ++i){<br />
}<br />
my problem here is that:
for example when NUM=1000, it takes 20 seconds to complete, when I tried 1500 it took more than 60 seconds which is unrealistic because each loop takes the same time. I tried to stop the loop when i=1000 but NUM is still = 1500 to see when it does finish, I was shocked to see that 60 seconds was required to do the 1000!! how could this possibly be?
P.S: I did NUM=1200 and 1400 and they all took 20 seconds to complete the 1000!! why does 1500 is different?
another thing, is multithreading useful to speed up long operations?
I have read about it and know that it is useful when I want more than one process to be executed at the same time, but what if I only have one process, does it speed it up or something?
thanks,
-- modified at 21:46 Wednesday 25th April, 2007
|
|
|
|
|
The only thing that speeds up long operations is more powerful machine. Multithreading can only prevent long operations blocking other operations, and to be picky, it will actually slow the long operation down by a minuscule factor. The whole point there is being able to do other things while the long operation is churning away in the background.
|
|
|
|
|
Brady Kelly wrote: The only thing that speeds up long operations is more powerful machine
I strongly disagree. You can apply a better algorithm, choose a better implementation,
or improve parallellism, which is able to reduce the overall time provided there
were spare CPU cycles to begin with (indicating part of the code is either waiting
on some resource, or just sleeping for some reason).
For some resources, behavior is non-linear; AFAIK sockets use some resources that
are available to some extent, and include a delay before getting freed automatically.
|
|
|
|
|
OK, maybe my answer was grossly over simplified, and for that it should also been much shorter.
|
|
|
|
|
thanks for the info guys.
|
|
|
|
|
I'm betting this loop can be made faster if the access to the DB is optimized. What I mean by that is: Does the DB really need to be accessed each time through the loop? If the answer is no, then create a conditional that will only access the DB when it is necessary.
Another way to look at this is to do all of the DB access at once. In other words, split your processing up. Do the calculations and store them in a manner that is efficient for later DB access once the calculations have been finished (after the calculation loop is completed).
Without knowing much about what the calculation is, why the DB access needs to be done, and how the data in the DB is affected, I can't give a good answer on how to split the processing up.
Phil
|
|
|
|
|
pbraun wrote: Does the DB really need to be accessed each time through the loop?
Yes, it does. It accesses the DB seeking for some different info each time.
About doing all the DB access at once, I can see what do u mean, but does it really make a difference? I can split the loop into 2 loops(with the same lenght). the first one is to access the DB and the other to do the calculations.
pbraun wrote: Do the calculations and store them in a manner that is efficient for later DB access once the calculations have been finished
Actually, my calculations depends on the values retrieved from the DB, that is, I have to access the DB first, get some values, do calculations, have result and then next loop.
Also, the data in DB is never affected. This process only retrieves records.
I can simplfy the process as following:
<br />
for (int i=0; i<NUM ; ++i){<br />
<br />
"SELECT * FROM TABLE WHERE CONDITION";
<br />
while (reader->Read()){<br />
<br />
<br />
<br />
}<br />
<br />
reader->>Close();<br />
<br />
}<br />
<br />
|
|
|
|
|
Hmmm. From that description, it seems that it would be better to send one query to the DB that retrieves all of the necessary data from the DB, then do the processing (in your case, calculations).
It is my opinion, that the constant queries to the DB is costing you the time. Of course, you will then have the problem of memory management if your number of data becomes sizable. In that case, you may want to complicate your algorithm by reading in up to a predetermined number of records, doing some of the calculations, then reading in the next batch of records, and so on until finished. This will minimize the DB access.
Phil
|
|
|
|
|
pbraun wrote: it seems that it would be better to send one query to the DB that retrieves all of the necessary data from the DB, then do the processing (in your case, calculations).
I'm afraid that it is not possible in my case, my condition is already complex enough at each loop  , also it depends on some data outside the loop ...
pbraun wrote: the constant queries to the DB is costing you the time
Yes, the queries are costing much of the time!
I would like to ask also does the .NET framework do anything behind the scene when a long operation is in run?
I have encountered a warning when "another" long operation was running:
The CLR has been unable to transition from COM context 0x1a2008 to COM context 0x1a2178 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.
Thanks for your help Phil, I really appreciate it 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
