Closed GoogleCodeExporter closed 8 years ago
I designed FlMenu::userData only for integer data type.
(Because I prefer indexes to pointers.)
So I think it is safe to force the type casting.
would reinterpret_cast<int> work? I can't be sure because I don't have access
to any x64 os at the moment.
I would appreciate a feedback very much if you fix the compile error.
Original comment by taesoob...@gmail.com
on 5 Dec 2010 at 6:15
on x86_64 (linux) platform,
sizeof(int) is 4
sizeof(void*) is 8
so the code is not portable
sizeof(unsigned long) is 8 also under x86_64, but is 4 under win64, so I
suggest use
unsigned long long instead
Now I don't have my laptop at hand, so I maybe provide a patch tonight.
Original comment by wanng.fe...@gmail.com
on 6 Dec 2010 at 1:08
I meant that 8 bytes are enough for storing integer (4-bytes).
Userdata in FLTK is not used at all in FLTK, and it's there for users'
additional storage. Users can use the userdata for whatever purpose they want.
And as you mentioned, the size of the storage is 8bytes in x86_64 and 4bytes in
x86_32 (enough for holding a pointer). But I decided to use it to store 4-byte
integer instead of pointers.
In this assumption, unsigned long long is not portable in x86_32 because the
4-byte storage area cannot hold unsigned long long.
It would have to be either (void *) or (int) to be portable.
Do you understand what I mean?
Original comment by taesoob...@gmail.com
on 6 Dec 2010 at 2:36
please take a look at the patch attached within this comment, it works on
x86_64.
Original comment by wanng.fe...@gmail.com
on 6 Dec 2010 at 3:50
Attachments:
[deleted comment]
I think the following should work too.
if (sizeof(void*)==8)
{
long long sig1 = reinterpret_cast<long long>
((m_aMenuItem[m_pMenu->value()].user_data())user_data());
return static_cast<int>(sig1);
}
else return ... // as it was before
If you don't like the integer truncation, (void*) would be a better choice.
it's good to know that it runs on x86_64 though.
Thanks.
Original comment by taesoob...@gmail.com
on 6 Dec 2010 at 4:07
thanks for you good job.
this issue could be closed now.
Original comment by wanng.fe...@gmail.com
on 6 Dec 2010 at 4:11
Hi, I have compiled papercrop with the patch above on Ubuntu 64. It runs and
show the main window but when I click on any button it doesn't show anything.
On terminal I have only this:
#./paperCrop
Xdbe not supported, faking double buffer with pixmaps.
pFileName=presets/default preset.lua
Nothing relevant I think. Any suggestion?
Thanks in advance.
Original comment by chemistr...@gmail.com
on 14 Dec 2010 at 3:32
The terminal output is normal.
Did you try to click the load button?
Do you mean absolutely no reaction, no crash?
That's strange.
I would 1. debug build (-g), 2. set a break point on the onCallback function
and see what's going on.
Original comment by taesoob...@gmail.com
on 14 Dec 2010 at 7:25
Exactly no reaction, no crash, no errors in console... I have tried to do it
all again but still the same. I don't know how to debug it, maybe you can give
me some instructions or is it too complicated?
Windows version runs ok through wine but I suppose a native 64 bit compilation
would be faster. Anyway, the app is great, now I can really read pdf in my
ebook. Thanks!
Original comment by chemistr...@gmail.com
on 14 Dec 2010 at 10:26
Could you try the following modification (RightWin.cpp) and show me the console
output?
-------------------------------------------
...
#include <FL/Fl_Native_File_Chooser.H>
void RightPanel::onCallback(FlLayout::Widget const& w, Fl_Widget * pWidget, int
userData)
{
printf("Debug:%s\n", w.mId.ptr()); // I only added this line for debug
if(w.mId=="update")
...
Original comment by taesoob...@gmail.com
on 15 Dec 2010 at 4:04
I have just do it, I think you meant file RightPanel.cpp instead of
RightWin.cpp. I have compiled it with that mod but the console output is still
the same, even pressing all buttons.
Original comment by chemistr...@gmail.com
on 15 Dec 2010 at 4:44
I installed ubuntu 64 on one computer and built papercrop with a few
modifications.
It seems to run ok. Please try to update the svn folder and rebuild.
I used the dependencies listed in install_dependencies_ubunth.sh
Thanks,
Taesoo.
Original comment by taesoob...@gmail.com
on 17 Dec 2010 at 1:43
[deleted comment]
Nice, it works and is really much faster! Maybe twice or more than with
32 bit and wine. Again thank you very much!
Original comment by chemistr...@gmail.com
on 17 Dec 2010 at 3:05
Original comment by taesoob...@gmail.com
on 3 Feb 2011 at 5:22
Original issue reported on code.google.com by
wanng.fe...@gmail.com
on 5 Dec 2010 at 7:10