|
Moi, je te donne 1 pour ton incompréhension à comprendre le problème.
-----
Formerly MP(2)
If atheism is a religion, then not collecting stamps is a hobby. -- Unknown
|
|
|
|
|
Le Centriste wrote: incompréhension à comprendre
|
|
|
|
|
Je voulais dire "incapacité". Mauvais choix de mots.
En passant, tu liras la fin du thread et tu comprendras pourquoi ce n'était pas nécessaire de poster le code complet.
-----
Formerly MP(2)
If atheism is a religion, then not collecting stamps is a hobby. -- Unknown
|
|
|
|
|
For the umptiest time, no one asked for the complete code, just the relevant code.
BTW the majority of people in Belgium speak Dutch, not French.
(and most of them know French sufficiently to spot mistakes) 
|
|
|
|
|
I thought most people in Belgium spoke Flemish...
-----
Formerly MP(2)
If atheism is a religion, then not collecting stamps is a hobby. -- Unknown
|
|
|
|
|
Hello,
I'm trying to get the mime type of a file like (application/msword)
that determine the application that will open this file and its extension but I can't do it in my windows app.I want to know how to get the type of a file and how to get the extension from this type.
Thanks.
Dad
|
|
|
|
|
If you are just trying to open the file up, use the following code and Windows will do the work for you with any registered mime type.
I use this to open up .PDF files saved in the database automatically.
System.Diagnostics.Process.Start(file name here);
Hogan
|
|
|
|
|
Great thanks,
but I want to send the mime type to a server that running a file net engine that require the mime type like we do in web apps by using the file upload control ,this is the first part the second is I want to get the extension when I get the file back from the server to write it to the client hard desk by its right extension.
I need help in this .
thanks.
Dad
|
|
|
|
|
I have a program that loads in a large image (14000x10000 pixels) & resizes the image to fit on the screen. Once it is resized I track the pixel that the mouse is over. This is reported back as the actual location on the screen (somwhere within the 1280x1024 of the screen resolution). I would like to know how to get the actual location within the larger image.
Any thoughts?
Thanks
R.Myers
|
|
|
|
|
Just multiply the coordinates with the same scale that you used to shrink the image.
---
single minded; short sighted; long gone;
|
|
|
|
|
If you select one pixel on your screen, the corresponding location on the original
image would be an entire rectangle with approx dimensions of 12*14; its location
can be found as Guffa already explained, as well as its exact size.
|
|
|
|
|
Thanks Luc & guffa.
I think that'll work. (It looks pretty obvious when you said it )
R.Myers
|
|
|
|
|
[I thought I had found my answer earler so I had deleted the other post, but I didn't.]
I am working with data where records are stored in big and little endian.
For example a file has:
16 fields some are intergers and some a doubles and half are stored in big
and the other half in little.
I know that my system should be in a little endian state but..
How do I convert from big to little and little to big?
God Bless,
Jason
DavidCrow wrote: It would not affect me or my family one iota. My wife and I are in charge of when the tv is on, and what it displays.
I do not need any external input for that.
|
|
|
|
|
The Windows Sockets library has built in functions or you could write your own using bitwise manipulations.
|
|
|
|
|
Hi,
I dont think mixing big-endian and little-endian data in a single file is a good idea.
If only one type of system is involved, convert the "wrong endian" data before storing
it; it different types of systems are involved, select one type, and let the systems
with the other convention do all the conversions every time.
Anyhow, you can change from one to the other with simple byte swapping
BTW the code is the same for either direction i.e. big2little and little2big
are no different.
The code can be based on byte extraction/insertion (using and, shift, or),
or on a union-like construct (using a struct with FieldOffsetAttribute).
|
|
|
|
|
Luc Pattyn wrote: I dont think mixing big-endian and little-endian data in a single file is a good idea.
I agree. The problem is that the data files are created by another applications and I don't think I will be able to change their think on the subject.
Anyways I think I figure out a to flip them.
Correct me if I'm wrong if you have a 32bit integer (int32) it has 4 bytes.
So we could say a int32 bytes like this WXYZ flip to ZYXW.
If that is correct then my method works just fine.
static byte[] FlipBytes(byte[] bArray)
{
byte[] bNewArray = new byte[bArray.Length];
int j = 0;
for (int i = bArray.Length - 1; i >= 0; i--)
{
bNewArray[j] = bArray[i];
j++;
}
return bNewArray;
}
God Bless,
Jason
DavidCrow wrote: It would not affect me or my family one iota. My wife and I are in charge of when the tv is on, and what it displays.
I do not need any external input for that.
|
|
|
|
|
Yes, that is correct.
And a good way if you start off with a byte array.
If you start off with a long, an int, a short then it would be a pitty to first
create a byte array.
BTW you may not need the new byte array, you could swap bytes in situ:
it suffices to loop over half of the bytes and swap them (using one temporary byte).
int lenMinus1=bArray.Length-1;
for (int i = 0; i <= lenMinus1/2; i++) {
int j=lenMinus1-i;
byte temp=bArray[i];
bArray[i]=bArray[j];
bArray[j]=temp;
|
|
|
|
|
Luc Pattyn wrote: Yes, that is correct.
Thanks I got one right
Luc Pattyn wrote: If you start off with a long, an int, a short then it would be a pitty to first
create a byte array.
Why would it be bad to create a byte array?
Luc Pattyn wrote: you could swap bytes in situ:
I think I might just do that.
Thanks for you input.
God Bless,
Jason
DavidCrow wrote: It would not affect me or my family one iota. My wife and I are in charge of when the tv is on, and what it displays.
I do not need any external input for that.
|
|
|
|
|
jason_lakewhitney wrote: Why would it be bad to create a byte array?
It is not bad, but why create and work with an object if there exists a simple
solution without such object.
Hence, if you start off with a byte array, operate on it; if you start off with
a long/int/short, operate on it. Example:
ushort val=0x1234;
val=EndianChanged(val);
...
public ushort EndianChanged(ushort val) {
return val=(val>>8) | (val<<8);
}
As you can guess, this method is much cheaper than the byte-array based solution,
it is less code and no new objects.
Of course, if you need this endian changing only a couple of times, it does not
matter how you do it. If you are going to read an entire binary program file,
maybe several MB in size, it may well matter.
r
|
|
|
|
|
Okay I did a test to understand whats going on and verify the correct method to use
and this is what I came up with:
234
Array Flip: -369098752
Int Shift: 59904
IPAddress: -369098752
The reason why I wanted to write my own method instead of using IPAddress is so that I
could understand whats going on and also I don't want to have to referance it.
I am not trying to be a pain I just want to know which is right and I'll use it.
God Bless,
Jason
DavidCrow wrote: It would not affect me or my family one iota. My wife and I are in charge of when the tv is on, and what it displays.
I do not need any external input for that.
|
|
|
|
|
Hi,
I am not sure I understand your last message completely, here are some thoughts:
- my val=(val>>8) | (val<<8) code is probably not completely accurate, I guess
it will need an overall cast to get rid of the intermediate data type (without
it, the compiler would complain; and when changing the return type, the value
would be wrong, since the left shift must loose its top byte).
- I dont see how it would ever turn (0,0,0,234) into (0,234,0,0).
- for testing purposes it is best to use a hex number that fills the variable,
so for an ushort I would use 0x1234, for a uint 0x12345678; this gives a maximum
of information while debugging
- yes you can use IPAddress.HostToNetworkOrder, but that is not what I would do
since the method's name does not reflect the intention. You could hide it
inside your own ChangeEndianness() method tho.
|
|
|
|
|
Okay, its a new day lets look at this again.
using hex 0x12345678 = 305419896 that
gives us an array of bytes:
Byte: 120
Byte: 86
Byte: 52
Byte: 18
(If I am thinking correctly)Switching this from little endian to big endian
we would need to basically reverse the order of the bytes:
Byte: 18
Byte: 52
Byte: 86
Byte: 120
which is hex 0x78563412 = 2018915346
val = (val >> 8) | (val << 8) gives us:
Byte: 86
Byte: 124
Byte: 86
Byte: 52
which is hex 0x34567C56 = 878083158
Using your -val = (val >> 8) | (val << 8)- we are shifting bits, but I didn't think that is what
the problem is. For assumption was that big and little endian determined which way the bytes were
laid out. For example: 0x12345678 has 4 bytes(32-bits)-bytes:Z=120,Y=86,X=52,W=18. Now this is in
little endian basically because this machine uses little endian. Or in other words the bytes are read right to left in a least to greatest manner. Say that big endian is the opposite, then big read left to right in a least to greatest manner also. Big endian byte arrangement to 0x12345678 would be: W=18, X=52, Y=86, Z=120.
I am questioning things not to be a pain, but to make sure I understand. It seems to me that your are trying to shift bits when what is need is the bytes' order to be reversed. Yes/No
God Bless,
Jason
DavidCrow wrote: It would not affect me or my family one iota. My wife and I are in charge of when the tv is on, and what it displays.
I do not need any external input for that.
|
|
|
|
|
Hi,
the example I gave was handling unsigned shorts, these hold two bytes, hence the
formula included just one OR operator.
For (unsigned) ints, you need to swap 4 bytes, hence 3 OR operators; plus some
masking to avoid bit aliasing.
You could also do it pseudo-recursively like so:
// Swaps all bytes of a uint
public static uint Swap(uint val) {
return (uint)( swapLowerTwoBytes(val)<<16 | swapLowerTwoBytes(val>>16) );
}
// Swaps a ushort (but accepts and returns it as a uint)
public static uint swapLowerTwoBytes(uint val) {
ushort sval=(ushort)val; // throw away top bytes
return (ushort) ( (sval<8) | (sval>8) );
}
Both methods look very similar, I added the (uint) cast for clarity although
it is not needed; both (ushort) casts are necessary to throw away irrelevant bytes.
For signed int, it is similar, but be careful the sign bit gets replicated when
shifting right; either use an explicit AND, or cast to unsigned first.
Hope this helps.
BTW: when I told you to use a recognizable hex test value, the basic idea
is to do all printout in hex too !
|
|
|
|
|
Thank you for the time you spent on this matter.
I think we've got it worked out.
God Bless,
Jason
DavidCrow wrote: It would not affect me or my family one iota. My wife and I are in charge of when the tv is on, and what it displays.
I do not need any external input for that.
|
|
|
|
|
You are welcome.
I hope you are sure you understand the problem and the solutions (with and
without byte array).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
