C / C++ / MFC

HakunaMatada3-Jan-07 1:05

HakunaMatada

3-Jan-07 1:05

The Length of the String is somewhere around 268 characters and when it reaches the DDE Server, it adds random characters at the end increasing the length of the string to 284. Any idea why this happens?

---

Hakuna-Matada Beer | [beer]

It means no worries for the rest of your days...
It's our problem free, Philosophy
Jig | [Dance]

"I think my response was 'What idiot dreamed this up?'" -- Mary Ann Davidson, Oracle's chief security officer, in typical blunt manner, remembering her reaction to the company's scheme to brand its databases as "unbreakable."

Ray Kinsella3-Jan-07 1:14

Ray Kinsella

3-Jan-07 1:14

sounds like a string termination problem, Windows NT manages memory slightly better, sounds like when you are copying the string into the DDE buffer you aren't terminating it in whatever way it wants it to be terminated. Look up the documentation ... but as a quick fix I would try using ZeroMemory on the buffer before I copied anything into it.

Regards

Ray

"Je Suis Mort De Rire"
Blogging @ Keratoconus Watch

HakunaMatada3-Jan-07 2:15

HakunaMatada

3-Jan-07 2:15

Thanks a lot. Will look into it and get back to you tomorrow.

Again... Thanks for helping me out.

---

Hakuna-Matada Beer | [beer]

It means no worries for the rest of your days...
It's our problem free, Philosophy
Jig | [Dance]

HakunaMatada5-Jan-07 17:20

HakunaMatada

5-Jan-07 17:20

Hi again,

I am not not sure if it is a String termination problem. I investigated the matter further and found that the length of the string changes when it reaches the Server. I even tried self terminating the string by adding '\0' at the end of the string but to no avail.

In the end, what I did was this.
1. Find the length of the string.
2. Convert the length of the string to a 5 digit string.
3. Add the length string to the beginning of the string being sent from the DDE client.
4. After the DDE server receives the string, parse the string to extract the first 5 characters and get the number from it. Then just extract the exact length from the rest of string.

And it works fine. I know this is a very bad workaround but it got the job done. Any reason why this shouldn't be used in a production environment?

Thanks a lot again. Smile | :)

---

Hakuna-Matada Beer | [beer]

It means no worries for the rest of your days...
It's our problem free, Philosophy
Jig | [Dance]

uml question

omidcomputer2-Jan-07 23:40

omidcomputer

2-Jan-07 23:40

do you can help me with rational rose please?

Re: uml question

prasad_som2-Jan-07 23:55

prasad_som

2-Jan-07 23:55

You could get help from this[^] forum.

Prasad
Notifier using ATL | Operator new[],delete[][^]

hex values to words

flippydeflippydebop2-Jan-07 23:37

2-Jan-07 23:37

hey guys... im sure someone here will be able to help me with this one.

Im looking at a log file that contains hex values

I have a hex string that contains a date and time

0xd4, 0x16, 0x12, 0xbe

The date is Word1 and the time is word2:

The date is contained in 0xd4, 0x16
The time is contained in 0x12, 0xbe

I know that each one of these 0x hex vlaues is a byte.
I know that a word is two bytes

Now here is where i am stuck because i dont know how to amalgamate the two bytes together.

Should i be adding them togther or should i be using the MAKELONG API which puts 1 byte
as the high word and the second as the lowword??

Christian Graus3-Jan-07 0:23

Christian Graus

3-Jan-07 0:23

MAKELONG won't do it, a LONG is too big.

0xd4 << 8 + 0x16 will do it, in the first instance. You need to shift one value by 8 bits, so it sits above the other one.

Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog

flippydeflippydebop3-Jan-07 0:43

3-Jan-07 0:43

ahhh.. i see what your saying..

so 0xd4 = 11010100 and 0x16 = 00010110.

by shifting 0xd4 8 places it becomes 1101010000000000 which leaves room to add the 0x16 to become 1101010000010110 (54294 dec)

Thats excellent.. Thanks mate.

is this the normal way i should be amalgamting hex values then?

flippydeflippydebop3-Jan-07 1:48

3-Jan-07 1:48

hey Christian, i seem to be tripping up over myself here.

so that works for the date part.. I did the same with the time part. So:

0xd4 <<8 + 0x16 = 54294 (date)
0x12 <<8 + 0xbe = 4798 (time)

now do i add these two results to equal 59092 or do i need to do:

54294 << 16 + 4798.

Doing this though me a massive value: 3558211584

David Crow3-Jan-07 5:35

David Crow

3-Jan-07 5:35

What date does 54294 represent, and what time does 4798 represent?

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb

flippydeflippydebop4-Jan-07 0:38

4-Jan-07 0:38

Sorry i was getting myself in a twist.

the full 4 bytes represent the date AND time which means that i need
to amalgamate the full 4 bytes into a DWORD. (which is 4 bytes or 2 words)

0xd4 <<8 + 0x16 = 54294 (date)
0x12 <<8 + 0xbe = 4798 (time)

so the datetime value is actually:

54294 << 16 + 4798.

3558211584

which i believe to be seconds since the year 1996. - However i am having trouble converting this value to an actual time now! - i am trying to get it into a SYSTEMTIME struct.

"synchronized" method call in dll

David Crow4-Jan-07 3:24

David Crow

4-Jan-07 3:24

flippydeflippydebop wrote:
which i believe to be seconds since the year 1996.

Since 1996 is not considered a special year by the computer, you'll need to add the appropriate number of seconds to that value so that it reflects date/time since, for example, 1-Jan-1970. That's roughly 820,454,400. Now you can use the date/time functions that handle values from 1-Jan-1970.

"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15

"Judge not by the eye but by the heart." - Native American Proverb

trumper2-Jan-07 23:21

trumper

2-Jan-07 23:21

Hi, I am trying to write a "synchronized" function call in my dll so that programmers that use my api can expect to only make single-instance function calls. The basic motivation is that each function call spawns a thread hence I would like to greatly restrict the number of threads spawned (basically 1-and-only-1 thread spawn per function call to my api).

//In my program.h header file
int threadCode = 0; //no problem if threadCode is instantiated in the header file
HANDLE threadMutexEvent;
#define PROC_THREAD 0
#define ERR_THREAD_INUSE 1

//In my program.cpp program file
BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) {
//problem arises if I instantiate threadCode here
//threadCode = 0;

threadMutexEvent = CreateEvent(NULL, false, true, "MutexEvent");
return true;
}

int WINAPI processRequest() {
WaitForSingleObject(threadMutexEvent, INFINITE);
if(threadCode == PROC_THREAD) {
threadCode = ERR_THREAD_INUSE;
SetEvent(threadMutexEvent);
} else {
SetEvent(threadMutexEvent);
return ERR_THREAD_INUSE;
}

//spawn thread to do some work for me
return 0;
}

As you can see, I am using Win32's synchronization mechanism to do some simple synchronization on the global variable threadCode. As seen in the code comments listed above, everything is fine if I instantiate threadCode in the header file, however, once I shift the instantiation of threadCode to DllMain the synchronization gets messed up. Basically, seperate function calls to processRequest would always "see" threadCode == PROC_THREAD and go ahead to spawn another thread (which is what I am trying to prevent Frown | :(

If all things fail I would fall back on leaving the instantiation in the header file, but I am really curious as to why the 2 seemingly identical instantiation calls would result in 2 drastically different results.

Thanks

David Leyva3-Jan-07 6:54

David Leyva

3-Jan-07 6:54

Hi
I think the reason is that in the first case (var in header) initiation is only one time execution, but in the second case depends on dll instance.

I think your variable have to be static, try that way

Regards

David

trumper3-Jan-07 15:02

trumper

3-Jan-07 15:02

Hi David,

Thanks for the reply. I have tried using static and got the same result. I am quite sure only one instance of the dll is being loaded each time my test application is using it as I have other code in DllMain that clears the UI of all user input (which I don't see happening).

Thanks

David Leyva3-Jan-07 18:19

David Leyva

3-Jan-07 18:19

Another idea is replace current sync code instead a simple critical section. You have to init cs in DllMain I think that should work and is simple.

David

David Leyva3-Jan-07 18:23

David Leyva

3-Jan-07 18:23

Sorry, but I think that is not a good idea put a Global var in a header file.

Put all global vars in the cpp file. In the header file only function ptototypes.

Regards

David

trumper4-Jan-07 16:13

trumper

4-Jan-07 16:13

Hi David,

I took your advice and things seem fine now. No more global variables in the header file for me anymore Laugh | :laugh:

Thanks

i want to read that file

naveen padiyar2-Jan-07 20:41

naveen padiyar

2-Jan-07 20:41

i want that file this symbol ü to Content-Type: text/html; charset=ISO-8859-1,how read that file.
file is

FILE IS -------

D\ ü T^ V ived: by 10.82.180.5 with HTTP; Mon, 11 Dec 2006 20:39:06 -0800 (PST)
Message-ID: <c77d80a30612112039v121c49a6q2ab957200afe158a@mail.gmail.com>
Date: Mon, 11 Dec 2006 20:39:06 -0800
From: "hiimnsp uknowthatname" <uknowthatname@gmail.com>
To: uknowthatname@gmail.com
Subject: sub 15 it world
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_151408_4186001.1165898346884"
Delivered-To: uknowthatname@gmail.com

------=_Part_151408_4186001.1165898346884
Content-Type: teT^ ü d` D\ lain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

hi naveen hru .
give me some detail about it world and other thingh .
tell me some concious way .
all r right .
naveen padiyar

------=_Part_151408_4186001.1165898346884
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

hi naveen hru .
give me some detail about it world and other thingh .
tell me some concious way .
all r righd` ü T^ br>naveen padiyar

------=_Part_151408_4186001.1165898346884--

-- modified at 6:09 Thursday 4th January, 2007

naveen padiyar

ü'" "' " (It's simple)

<color>Aljechin 2-Jan-07 21:35

<color>Aljechin

2-Jan-07 21:35

^ ü@ 3 d` D

Hamid_RT3-Jan-07 1:18

Hamid_RT

3-Jan-07 1:18

WhiteSky

Mark Salsbery3-Jan-07 7:07

Mark Salsbery

3-Jan-07 7:07

Hamid_RT3-Jan-07 17:41

Hamid_RT

3-Jan-07 17:41

I guess maybe my database is old or bad command or... Big Grin | :-D

WhiteSky