C / C++ / MFC

dazinith7-Apr-03 9:51

dazinith

7-Apr-03 9:51

ah.. ya i guess that might be a possibility.. dunno.. good luck tho

still a newb.. cut me some slack :P
-dz

Joe Woodbury7-Apr-03 9:44

7-Apr-03 9:44

Three are ways to do this, but you are better off buying a test program already designed to do such things. Of course, it's likely that despite all the rhetoric your boss doesn't actually believe in testing so this will likely never happen.

J. Dunlap7-Apr-03 9:54

J. Dunlap

7-Apr-03 9:54

There are a number of ways to do it:

Named Pipes (I have an example of this if you're interested)
Semaphores (Global memory which is managed by a "semaphore" which makes the threads wanting to use the memory "wait in line")
Windows Messages (register your own, do WM_COPYDATA, or, yes, you can send mouse messages and keystrokes)

If you didn't create the app and it doesn't do OLE, you'll have to send keystrokes.

"Do unto others as you would have them do unto you." - Jesus

"An eye for an eye only makes the whole world blind." - Mahatma Gandhi

James A Beggs7-Apr-03 10:09

7-Apr-03 10:09

I didn't create it; and I'm not sure if it does OLE; perhaps the devs here can tell me - if they will take the time out for it.

I'm guessing that the Windows Messages would be best way all total (I'm reading up on win32 APIs, FindWindow function, and other stuff.

But I would be interested in your Named Pipes example, and any thoughts on which of these is the best approach and why, would be great.

James A Beggs
Microsoft MSN Mobile Component Test Team

Joe Woodbury7-Apr-03 11:00

7-Apr-03 11:00

James A Beggs wrote:
I'm guessing that the Windows Messages would be best way all total (I'm reading up on win32 APIs, FindWindow function, and other stuff.

It's a terrible way since you can't inject messages into another application and even if you could, it's not how users use the software. Testing software will mimic keystrokes, mouseclicks and mouse moves.

(And what if the software actually examines what keys are currently pressed?)

James A Beggs7-Apr-03 11:18

7-Apr-03 11:18

Well then, what would you suggest? I need to write code to mimic the keystrokes.

And no, I don't need to buy it; they are looking for me to prove I can develop software, not that I can make wise choices on buying it. Otherwise, it isn't going to help me for where I want to go and need to be.

James A Beggs
Microsoft MSN Mobile Component Test Team

Joe Woodbury7-Apr-03 11:30

7-Apr-03 11:30

James A Beggs wrote:
Well then, what would you suggest? I need to write code to mimic the keystrokes.

Don't remember. I did this once years ago and have never done it since. It was on Windows 3.11, but it would have worked on Windows 9x. It wouldn't have worked on NT/2K/XP due to how the input queues have changed.

James A Beggs7-Apr-03 10:11

7-Apr-03 10:11

Actually, my boss DOES believe in testing - thats what I'm here for, to test.

The problem is that I'm a short term contracter here, and I have been doing short term contracts for 3 years.

My boss just told me that one of the ways to go full time is to show my ability to code, and suggested this route. I'd actually like to be either a Dev in Test or a Developer, and I do have a BS in Computer science and some coding skills, but as I said before, I never worked with other people's apps, or wrote apps to work with other apps; all stand alone stuff, and for the last three years all I could land is testing positions.

I fear my skills will be degrading. I'm going to have to work harder at self-education to get myself up to speed. Frown | :(

James A Beggs
Microsoft MSN Mobile Component Test Team

Joe Woodbury7-Apr-03 10:57

7-Apr-03 10:57

How about if you show your boss that you can save the company lots of money by buying a testing application rather than writing one?

The problem is test bosses tend to talk alot about how they believe in testing and hire lots of people to prove it, but you can't get them to spend a dime on software to actually help with the testing. (Sometimes, you can't even get them to buy bug reporting software, though that also involves engineering and support.)

The best proof of a good tester isn't an ability to code, but an ability to find bugs--your goal should be to prove that developers are idiots. And when the developers claim to have fixed the bugs, to show all the other crap they broke while doing so.

(One place where I want testers who know how to program is when testing APIs and class libraries, but that's fairly specialized. The problem with writing test software specific to an application is just that; it's specific to an application. On the negative side, it also tends to cause testers to limit their scope of testing to those things which can be scripted instead of the myriad of ~~idiotic~~ amazing things users actually do. On the positive side, it's a good way to do regression testing.)

James A Beggs7-Apr-03 11:20

7-Apr-03 11:20

This is something I can do if I wanted to remain a tester; I don't. I want to do development; or, development in test.

And for that, I need to prove my programming skills; it wont do much if I have other people's software do it for me! Smile | :)

James A Beggs
Microsoft MSN Mobile Component Test Team

J. Dunlap7-Apr-03 11:04

J. Dunlap

7-Apr-03 11:04

Some tips for sending input:

>Use keybd_input for Win95, and SendInput for >=Win98

>For activating the window, don't try the FindWindow function unless you know either the full class name or the full title of the window, and the exact case of all the letters in it. If you don't know either of these, make your own using EnumWindows().

"Do unto others as you would have them do unto you." - Jesus

"An eye for an eye only makes the whole world blind." - Mahatma Gandhi

James A Beggs7-Apr-03 11:21

7-Apr-03 11:21

what about for windows 2K and XP? Smile | :)

James A Beggs
Microsoft MSN Mobile Component Test Team

J. Dunlap7-Apr-03 11:52

J. Dunlap

7-Apr-03 11:52

What I meant was Win98 or above, including 2K and XP

"Do unto others as you would have them do unto you." - Jesus

"An eye for an eye only makes the whole world blind." - Mahatma Gandhi

James A Beggs9-Apr-03 12:07

9-Apr-03 12:07

Ah, ok. I misunderstood - or misread.

James A Beggs
Microsoft MSN Mobile Component Test Team

James A Beggs9-Apr-03 12:16

9-Apr-03 12:16

And how do I identify the window I need from the others I don't with EnumWindows()?

James A Beggs
Microsoft MSN Mobile Component Test Team

C++ Coding style

Emilio Guijarro7-Apr-03 9:16

Emilio Guijarro

7-Apr-03 9:16

Hi guys, here is a question from a C++ programming course.

We have to implement the BubbleSort algorithm over a STL list. As we know, STL lists haven´t got random access iterators, so we can only increment and decrement the iterators (we can´t use expressions such as "i = i-1"). What implementation is better?

a) Using an additional function to get the iterator pointing to the previuos element:

<br />
template<typename T><br />
inline T Prev(const T& i) {<br />
  T j = i;<br />
  return --j<br />
}<br />
<br />
template<typename T><br />
void Bubble(T Begin, T End) {<br />
  for(T i = Begin, i != End, i++) {<br />
    for(T j = Prev(End); j!=i; j--) {<br />
      if(*j < *(Prev(j))<br />
        swap(*j, *(Prev(j)));<br />
    }<br />
  }<br />
}

b) Do not use any adittional function, and just use "temporal" stack variables.

Guess the implementation Poke tongue | ;-P

I say that "a" is better, my taecher and my best friend think that "b" is better.

What do you think?

Thanks.

"When I look into your eyes, there´s nothing there to see, nothing but my own mistakes staring back at me"

Re: C++ Coding style

Joe Woodbury7-Apr-03 9:39

7-Apr-03 9:39

Benchmark it.

And realize that you're arguing about a bubble sort! Who cares how you implement it?

Re: C++ Coding style

Anonymous7-Apr-03 21:26

Anonymous

7-Apr-03 21:26

The question is not about the algorithm, is about correct implementation.

Thanks anyway.

Re: C++ Coding style

Joe Woodbury8-Apr-03 4:28