|
Hello All,
I'm writing a dll that paints on the screen a gdi object.
How would you recomed me to perform automated UI test ?
I would like to draw the gdi object on the screen and compare it with a storded image.
I know I can caputre the screen and compare it to that image, but i was thinking maybe using the visual studio 2010 UI Automated test.
Thanks,
berlus
|
|
|
|
|
I don't personally believe in automated GUI tests.
|
|
|
|
|
Hello experts,
which advantages does one of these two methods
return (string.Format("Device #{0}", devNr));
return ("Device #" + devNr.ToString());have over the other one?
They seem to produce identical results.
Ciao,
luker
|
|
|
|
|
They produce identical results. The first one is consider better because it uses less memory. The second version allocates memory for 3 strings ("Device #", result of devNr.ToString() and result of entire statement), which makes application consume more memory. The first one isn't (to my knowledge) creating such an overhead. If you need to use second form it's better to use StringBuilder class. And personally I consider first form more readable.
|
|
|
|
|
lukasz_nowakowski wrote: And personally I consider first form more readable.
I agree, String.Format is more readable, especially when you have a few more arguments.
|
|
|
|
|
I totally agree the 1st form is better, just on readability alone.
I'd question your point about the StringBuilder as a replacement for the second form, creating an instance of this type has some overhead, for small concatenations the string builder is worse than the code supplied in the OP, but it has become received wisdom that StringBuilder is more efficient.
I posted a link a while back http://www.yoda.arachsys.com/csharp/stringbuilder.html[^] to an archive of stuff John Skeet has written about c# amongst others. He has tested the received wisdom, and found it wanting, the section "So I Should Use StringBuilder Everywhere, Right?" is really the nub of the problem.
It's worth doing the test he suggests, for "small" concats the overhead of the StringBuilder outweighs the benefits (and dirties the code). For multiple concats (e.g. in a loop)
StringBuilder<code> is much more efficient.<br />
<div class="signature"><small>Dalek Dave: There are many words that some find offensive, Homosexuality, Alcoholism, Religion, Visual Basic, Manchester United, Butter.<br />
Pete o'Hanlon: If it wasn't insulting tools, I'd say you were dumber than a bag of spanners.</small></div>
|
|
|
|
|
Interestingly, the String.Format uses a StringBuilder...
|
|
|
|
|
I'm not convinced String.Format is more efficient than the straight concat, but I do think the format route is clearer.
Disassembling String.Format gives this line:
StringBuilder builder = new StringBuilder(format.Length + (args.Length * 8));
So it is likely that, as long as the argument passed average 8 characters or less, the StringBuilder will probably be more efficient at first glance. Of course, I haven't tested this, but it would be easy to rig a test to find out.
The point I was trying to make was that the assumption that StringBuilder is always more efficient than direct string manipulation is demonstrably false. Additionally, I'd say, unless the code is a block you know will be heavily repeated, early optimisation will ruin otherwise clear code without real benefit. I personally would only consider using a StringBuilder when I know this is the case, or testing reveals poor performance, or the system must perform with the highest possible efficiency for some reason(e.g. real time). This is in line with the KSS and YAGNI principles.
Dalek Dave: There are many words that some find offensive, Homosexuality, Alcoholism, Religion, Visual Basic, Manchester United, Butter.
Pete o'Hanlon: If it wasn't insulting tools, I'd say you were dumber than a bag of spanners.
|
|
|
|
|
I wasn't arguing for StringBuilder. I was just noting that you were saying for smaller concats, StringBuilder won't be more efficient. You were saying you preferred format 1 (albeit for readability) and I was just pointing out that format 1 used a StringBuilder which you were seeming to argue against.
I was just pointing out the irony is all.
For what he wrote, I would always lean towards the second format. Especially now that I've seen the path String.Format(String, Object) takes:
String.Format(String, Object) calls
String.Format(IFormatProvider, String, Object[]) calls
StringBuilder(int capacity) and StringBuilder.AppendFormat(IFormatProvider, string format, params object[] args) and StringBuilder.ToString() which calls
string.FastAllocateString(int length) then concatenates each of the StringBuilder parts.
It's way more code being run.
|
|
|
|
|
Not to mention that the first form makes localization easier between english and any of {French, Spanish, Italian, etc..}
|
|
|
|
|
Yes, I was going to make that point too.
|
|
|
|
|
I'm just curious about something here. The header for String.Format looks like:
string Format(string strInput, object objInput)
right? So, right away, a new string is created, along with a reference to the object.
Now, the code, would have to first find the starting and ending brace and pull out the formatting codes. Then, it would have to take the object and apply the formatting code to it and then return the part of the string before the brace, the formatted code, and the part of the string after the brace. In other words, if you had passed it "format {0} me", the return would look like:
return left(strInput, startingBraceIndex) & Format(objInput, formatCode) & right(strInput, strInput.Length - endingBraceIndex - 1)
or something like that. Of course, it is (hopefully) optimized a bit, so that it's not creating as many copies, but still, wouldn't more memory have to be used for the Format method, plus more processing cycles because or what all has to be done...whereas the second routine is much more straightforward.
As far as performance, I just don't see how the first is more efficient than the second. I also don't see how the first is more readable...even with more parameters, you would have to know what was in each spot in the array, so as far as readability, the second would be more readable as well.
Is
object[] objArray = {devNr, idNr, testNr};
return string.Format("Device #{0}, ID#{1}, Test#{2}", objArry);
really more readable than:
return "Device #" + devNr + ", ID#" + idNr + ", Test#" + testNr ?
Sure the first one is a bit cleaner, but IMO, it's not more readable.
Besides, whatever happened to Occam's Razor?
|
|
|
|
|
Interesting point... I was curious, so I checked String.Format with .NET Reflector... Actually it doesn't split string. Under the hood it uses StringBuilder.AppendFormat. Method is quite long and operates on char[] (from format.ToCharArray()). And I'm tired, so didn't trace the method body. Just took a look on it.
|
|
|
|
|
|
Hello, I need to pull data from another application. I have written to code to get it (using VirtualAllocEx, readmembory.. etc).
The program gets data for simple application, but for a particular application that I need, it doesn't seem to work, it returns empty string..
the application from which I need to retrieve data has a parent class named: Afx:00400000xx
I have used EnumChildWindow to loop through all the windows but it doesnt seem to produce any results
using Visual Studio 2003
Any help will be appreciated
Thanks
|
|
|
|
|
iceeeeman wrote: but for a particular application that I need, it doesn't seem to work, it returns empty string..
Please post some of your code to show where the problem occurs, the above tells us nothing.
It's time for a new signature.
|
|
|
|
|
Hi Richard, thanks for your prompt reply
ReturnString returns empty, here's the code that I've used
Win32.GetWindowThreadProcessId(ListViewHWND, out ProcessID);
ListViewProcessPointer = Win32.OpenProcess(PROCESS_VM_OPERATION | PROCESS_VM_READ | PROCESS_VM_WRITE | PROCESS_QUERY_INFORMATION, 0, ProcessID);
ListViewItemPointer = Win32.VirtualAllocEx(ListViewProcessPointer, IntPtr.Zero, (uint)Marshal.SizeOf(typeof(Win32.LVITEM)), MEM_COMMIT, PAGE_READWRITE);
ListViewPointer_item = Win32.VirtualAllocEx(ListViewProcessPointer, IntPtr.Zero, 1512, MEM_COMMIT, PAGE_READWRITE);
ListViewPointer_subitem = Win32.VirtualAllocEx(ListViewProcessPointer, IntPtr.Zero, 1512, MEM_COMMIT, PAGE_READWRITE);
ListViewItem.cchTextMax = 1512;
string[,] ReturnString = new string[300, 2];
int ReturnStringIndex = 0;
for(int i = 0; i < totalItem; i++)
{
ListViewItem.iSubItem = 0;
ListViewItem.pszText = ListViewPointer_item;
Win32.WriteProcessMemory(ListViewProcessPointer, ListViewItemPointer, ref ListViewItem, Marshal.SizeOf(typeof(Win32.LVITEM)), IntPtr.Zero);
Win32.SendMessage(ListViewHWND, LVM_GETITEMTEXT, i, ListViewItemPointer);
ListViewItem.iSubItem = 0;
ListViewItem.pszText = ListViewPointer_subitem;
Win32.WriteProcessMemory(ListViewProcessPointer, ListViewItemPointer, ref ListViewItem, Marshal.SizeOf(typeof(Win32.LVITEM)), IntPtr.Zero);
Win32.SendMessage(ListViewHWND, LVM_GETITEMTEXT, i, ListViewItemPointer);
IntPtr bytesReaded;
Win32.ReadProcessMemory(ListViewProcessPointer, ListViewPointer_item, ListViewItemBuffer, 1512, out bytesReaded);
Win32.ReadProcessMemory(ListViewProcessPointer, ListViewPointer_subitem, ListViewSubItemBuffer, 1512, out bytesReaded);
MessageBox.Show(ListViewSubItemBuffer+"");
ReturnString[ReturnStringIndex, 0] = Encoding.ASCII.GetString(ListViewItemBuffer);
ReturnString[ReturnStringIndex, 1] = Encoding.ASCII.GetString(ListViewSubItemBuffer);
ReturnStringIndex++;
}
|
|
|
|
|
I can see nothing obvious in the above, but since this is an extract there are a number of declarations missing. I would suggest you try stepping through your code with the debugger and verifying the correct values for your variables and pointers. Also please use the "code block" button when posting code to ensure it is surrounded by <pre></pre> tags.
It's time for a new signature.
|
|
|
|
|
Hi Richard, I tried using Stealing Program's Memory[^] in C#, and also in C++. They worked fine for the demo application provided with it, but when I tried to use it with a another application, I am just able to get the total number of Items in the Listview, without the Items
Could you please help
Thanks
|
|
|
|
|
Sorry but this is a system that I have never used. You could try posting a message in the forum at the end of the article to see if the author or any other user has the answer.
It's time for a new signature.
|
|
|
|
|
Hi
Is there any way to configure ASP.Net, C# application to store all the session values into custom storage.
Session["UserName"] = "XXX";
this has to call my own adopter and send the values rather than In-Memory/SQL Server.
Thanks
|
|
|
|
|
I don't know if this will address your question or not but it is bad practice to directly use the Session object in code. By using a static wrapper class you can have all calls to session centralized as well as strongly and statically typed (a good thing). You then have the freedom to completely control the underlying implementation.
The link below addresses a custom provider.
http://msdn.microsoft.com/en-us/library/ms178587.aspx[^]
|
|
|
|
|
My Qestion: It is possible to call the Class instance name I get with
FieldInfo[] myFieldInfo;
.......
myFieldInfo[i].Name
(Example from MSDN)
Thanks
|
|
|
|
|
Your question is not very clear. Could you clarify what exactly it is that you want to do?
|
|
|
|
|
Sorry for my unclear question.
What I want is to call a method via its class-instance name (I have already create a instance) at runtime from another class in the same assembly.
The problem is, I don´t know the class instance name at compile time.
So I get the name via reflection (FieldInfo class).
Probably a method like "methodInfo.Invoke" can do the job, but so far I´m understand
the class instance must known at compile time.
Thanks
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
