Register | Login
Views: 19364387
Main | Memberlist | Active users | ACS | Commons | Calendar | Online users
Ranks | FAQ | Color Chart | Photo album | IRC Chat
11-02-05 12:59 PM
0 user currently in Programming. | 3 guests
Acmlm's Board - I2 Archive - Programming - 64-bit integers in C?
  
User name:
Password:
Reply:
 

UserPost
HyperLamer
Posts: 3245/8210
That's basically the idea, although the window is actually one big button, so either button opens the menu. I threw in TPM_RIGHTBUTTON because I tend to find myself right-clicking it, so I figured why not? Otherwise, that's exactly how I did it.

[edit] Er, just to clarify... The window isn't actually a button, just a normal popup window. It just looks like a button.
Parasyte
Posts: 296/514
Am I correct in assuming that you want a menu to pop up when you right click anywhere in the window? If that is the case, this is what you need to do:

1) Call CreatePopupMenu() or GetSubMenu() to create a global handle to a menu. This should be done in your window initialization message handler (WM_CREATE or WM_INITDIALOG).
2) Call TrackPopupMenu() in your window's right click handler (WM_RBUTTONDOWN). The TPM_RIGHTBUTTON flag in TrackPopupMenu() is used to allow menu items to be clicked on (selected) using the right mouse button. It does not cause the menu to opened.
HyperLamer
Posts: 3240/8210
I know I read somewhere that origin was #2, and that did work in another program since I was reading byte 0 anyway. As for the rewind() I was just hoping that would fix it.

A small menu-related problem: Using TrackPopupMenu (with the TPM_RETURNCMD and TPM_RIGHTBUTTON flags), sub-menus won't appear until the option is clicked on. Do I need to do that manually or something like that?
Parasyte
Posts: 294/514
The origin is the 3rd argument, not the 2nd. And rewind() is not needed before fseek(). Also, you do not have to seek 4 bytes ahead after reading 4 bytes. The file pointer is always automatically incremented after a read. Finally, there are better ways to read integers.

fseek(file,0x12,SEEK_SET);
ImgWidth = getw(file); //Get width
ImgHeight = getw(file); //Get height


One note of caution: getw() (on x86-based machines) will read integers as little endian, so they are effectively byte swapped. If you don't actually want that (which is NOT the case when working with bitmaps, as you seem to be doing) you should use the following, instead (note how the args differ from yours):

fread(&ImgWidth,4,1,file); //Get width
fread(&ImgHeight,4,1,file); //Get height
HyperLamer
Posts: 3239/8210
That didn't seem to make a difference... it's working now though.
Originally posted by neotransotaku
I believe you have to change the default class's font to effect the command results...
But I don't want all unformatted files to look like that.

Now this I just don't get.
rewind(file);
fseek(file,SEEK_SET,0x12);
fread(&ImgWidth,4,4,file); //Get width
fseek(file,SEEK_SET,0x16);
fread(&ImgHeight,4,4,file); //Get height

Somehow, the first fseek() ends up at byte 0 and the second at 0x10. Even stranger is without the rewind(), the first one ends up at byte 2 but the second one at 0x16 like it should.
Parasyte
Posts: 291/514
You should always use a button definition with MessageBox:

MessageBox(NULL,"Message box!","Title bar!",MB_OK);
neotransotaku
Posts: 2178/4016
I believe you have to change the default class's font to effect the command results...
HyperLamer
Posts: 3238/8210
Er, I meant a specific font for the command results.

So what exactly would make MessageBox() not work? Even something as simple as MessageBox(0,"Message box!","Title bar!",0) just makes the box sound and hangs the program, but no box appears.

And how do I make the window not show up in the taskbar?
neotransotaku
Posts: 2172/4016
You can change the font by going to Tools->Preferences. In the resulting dialog box, there should be a node called "Document Classes" and under it should be "C/C++". Within C/C++ there should be node called Font and there you can change the font.

As for force wrapping, in the Command Results, I don't think so...
HyperLamer
Posts: 3220/8210
Cool, found it. Is it possible to force a specific font and width (IE wrap at 80 characters) for the Command Results though? My makefiles tend to use extended DOS characters and rely on the wrapping style the DOS box uses (mainly for separating program output from compiler output) so they look rather crappy in Textpad.
neotransotaku
Posts: 2157/4016
HH, for textpad, take a look at the settings they have for Java (install the java shortcuts even if you don't have it). Just do the same thing for gcc.
HyperLamer
Posts: 3203/8210
If you mean printing them with %I64d, that was an accident. I changed it to %1.2f, works fine. I just wanted actual decimals. If a program told you a file was 6 GB and it was actually 6.89, you'd probably be rather upset, especially if you're downloading it on a slow connection or low on HD space.
Parasyte
Posts: 289/514
Why on earth would you want to print a double as a base-10 integer? Hex, I can understand.
HyperLamer
Posts: 3197/8210
Poop, I completely missed that. Didn't think it would cause an overflow though.

Say, is there a way to specify a shortcut key in Textpad that will run a program in the directory the current file is in? It'd be nice to not have to switch windows back and forth to compile. (Yeah, I'm lazy. ) And also if it wouldn't crash when clicking Manage Files or Customize Toolbars.

[edit] Also, I changed b to a double (yes, I did the casting and such... printing doubles as %I64d gives weird results )... It works, but I'm just wondering if this might cause some problems? I've heard some systems do floating-point math differently than others, particularly with comparing to integers.
Parasyte
Posts: 283/514
There's the problem:
sprintf(Buffer,"%d %d %s",b,unit,Name[unit]);

You're passing a 64-bit variable to a format that expects 32-bit; effectively causing a nice little overflow. Each %d format will print half of 'b'. Then %s is used to print 'unit'. Obviously, %s expects a pointer. This is passing "0" as the pointer.

Now, I learned today that MinGW uses some of the native Windows DLLs for std functions (not libc or newlib, as I anticipated). Knowing this, you can head over to MSDN and look into the Microsoft printf specification. The prefix I64 (EYE-SIXTY-FOUR) can be used to print 64-bit integers:

sprintf(Buffer,"%I64d %d %s",b,unit,Name[unit]);
HyperLamer
Posts: 3155/8210
What, are you a compiler? I've posted all but a few lines already.

char WindowName[1024], TempStr[256];

//in WinMain()
FormatBytes(TempStr,1000,true);
printf("%s\n",TempStr);

//declaration
void FormatBytes(char* Buffer, unsigned long long Bytes, BOOL FullNames)
{
unsigned long long b = Bytes;
int unit = 0;
const char* Name[10] = {
"Bytes",
"Kilobytes",
"Megabytes",
"Gigabytes",
"Terabytes",
"B",
"KB",
"MB",
"GB",
"TB"
};
while((b >= 1024) && (unit <= 4))
{
b = b / 1024;
unit++;
}
if(!FullNames) unit += 5;
sprintf(Buffer,"%d %d %s",b,unit,Name[unit]);
}
Parasyte
Posts: 281/514
Wait, where did 'FormatBytes' come from? Your posts are missing far too much code, and veering off course. I can't figure out what either of those last to lines you posted has to do with any of your previous code. I would suggest pasting entire functions, and complete function calls (including definitions of variables and whatnot used therein).
Having only code snippits is causing confusion. Think of it as if you were giving these snippits to a compiler... It wouldn't know what to do, given only that information. Likewise, for any of us to compile and debug this code, we need every relevent line of code you are using.

Newlib is available here: (First link that showed up in Google. "I'm feeling lucky" would have taken you directly to it) http://sources.redhat.com/newlib/
HyperLamer
Posts: 3153/8210
It could be useful if you needed to write to I/O addresses or something, though not really useful, since you could just use #define instead..
Originally posted by neotransotaku
That's because you declared the stringarray variable as const. If you didn't declare it const, then you can write to it. Think about it, if it is const, none of that memory should change but you are changing that part of memory.

Er, right... It wasn't const in that.


as for your other code, where's the declaration of "Buffer"?

It's a function, actually. void FormatBytes(char* Buffer, unsigned long long Bytes, BOOL FullNames). b is just another unsigned long long that Bytes is copied into (rather than end up changing the variables that are passed... come to think of it, that wouldn't be an issue here would it?) I called it with this:
FormatBytes(TempStr,1000,true);
printf("%s\n",TempStr);

Where TempStr is a 256-byte char array. I get '1000 0 (null)' as a result. If I pass a value >=1024 for Bytes so that it would print a different string, it just crashes.

Para, I'm not sure exactly what, if anything, that code does different than mine did (I went and deleted it already), but I would just get the same result as what I have now. And maybe I just suck at Google but I can't seem to find Newlib downloads anywhere.
Dish
Posts: 274/596
Originally posted by neotransotaku
That's because you declared the stringarray variable as const.


const char* somepointer;

That's a non-constant pointer to a constant char. Meaning the pointer itself isn't constant, but what it points to is.

I believe to make the pointer itself constant.. you'd do:

char* const somepointer;

So that would mean the pointer itself is constant.. but what it points to isn't. I'm not 100% sure on this, because having a pointer that's constant is really useless.
Parasyte
Posts: 280/514
Originally posted by HyperHacker
I was doing it like this:
const char* stringarray[3];
stringarray[0] = "String 1";
stringarray[1] = "String 2";
[...]


I still don't see why that couldn't work, since they're constant strings; it should just be making stringarray[0] point to the first one and stringarray[1] point to the second?

That will work fine. I tested it, myself:
const char* stringarray[2];
stringarray[0] = "String 1";
stringarray[1] = "String 2";
printf("%s\n",stringarray[0]);

As you expect, it prints "String 1". Nothing too surprising, here.


Originally posted by HyperHacker
...And *surprise!* it doesn't work. I really don't see why this has to be so complicated.

int unit = 0;
const char* Name[10] = {
"Bytes",
"Kilobytes",
"Megabytes",
"Gigabytes",
"Terabytes",
"B",
"KB",
"MB",
"GB",
"TB"
};
while((b >= 1024) && (unit <= 4))
{
b = b /1024;
unit++;
}
if(!FullNames) unit += 5;
sprintf(Buffer,"%d %d %s",b,unit,Name[unit]);


It still just prints null for the first one and crashes with any others.

I don't see anything explicitly wrong with that, but it could be because I'm either half asleep, or because you neglected to include some code (the code that prints Buffer, and the definition of 'b' -- even though those are not important.)


Originally posted by HyperHacker
The %lld thing isn't working either:

long long x = 5000000000LL;
printf("%lld\n",x);

I still only get 705032704 (0x2A05F200) rather than 5000000000 (0x12A05F200) (whether x is signed or not).

You may need to download and install the latest version of newlib to get it working. I believe MinGW comes with libc, rather than newlib.
This is a long thread. Click here to view it.
Acmlm's Board - I2 Archive - Programming - 64-bit integers in C?


ABII


AcmlmBoard vl.ol (11-01-05)
© 2000-2005 Acmlm, Emuz, et al



Page rendered in 0.020 seconds.