![]() | Blog |
![]() | Releases |
Page:
0 ... 5 ... 10 ... 15 ... 20 ... 25 ... 30 ... 35 39 40 41 42 43 44 45 46 47 ... 50 ... 55 ... 60 ... 65
i.Ftp/Mac Changelog | |
---|---|
Date: 26/1/2007 | Test1:
Test2:
Test3 (unreleased):
|
(0) Comments | Add Comment | |
Smoke Test | |
---|---|
Date: 25/1/2007 | Can someone with a PPC Mac download this app and see
if it runs?
Update: Ok, the first attempt was a failure. But I've worked out how to embed a framework in a bundle after much head scratching and reading copious amounts of documentation. So the download link is the same, but I've updated the file it points to. Have at it then! |
(5) Comments | Add Comment | |
What I Fixed Tonight | |
---|---|
Date: 23/1/2007 | Well lets see, I fixed the list control selecting a whole range of items in one
click. I fixed the combo box not painting it's content. I fixed modal dialogs
gettings hidden behind the owning window. I made the text on buttons
darker. I fixed the saving of account settings, which brings me to the lovely
topic of printf formatting.
Ah printf formatting. It's nice and universal between platforms and every coder knows the basics by wrote. But it seems that the humble printf is to blame for a number of bugs in my software, mostly to do with the processing of 64bit integers. In the case of a 64bit integer passed to printf, 8 bytes are put onto the stack instead of the usual 4, so you have to instruct the printf command to expect that when crafting the format string. And this is where the trouble starts. Each platform has it's own lingo for that:
int64 Value = 1234; char s[256]; sprintf(s, "Value = " LGI_PrintfInt64 "\n", Value);Where LGI_PrintfInt64 is the format string for 64bit ints for your platform. The other case where it bit me is where I pass a single 64bit int to printf and use "%i" as the format. On Intel machines this works for values <4gb because of the byte ordering. On my PPC mac mini of course it doesn't work at all because the bytes are the other way around. Nevertheless you shouldn't do that, either cast it to an int or use the proper int64 formatting string. So I've uploaded a file and downloaded a file, created an account. i.Ftp is pretty usable right now. The only thing really outstanding is deleting local files, a few asserts in the FTP protocol code and working out how to package it into a .dmg release. But I feel good. The hard part is over... it's really down hill from here. |
(0) Comments | Add Comment | |
Porting... | |
---|---|
Date: 23/1/2007 | Ok context menus are working. I had to catch the message received in the owning window and route it back to GMenu::Float instead of receiving the value back from ContextualMenuSelect. Someone from the carbon-dev list helped me out there.
Then the menus were coming up in the wrong place... had to get the x,y ordering right to initialize the Point variable. Fixed. Then the combobox menus were coming up in weird places. Which was due to a bug in GView::PointToScreen(...). Fixed. Then fixed a bug in i.Ftp that would send you to ".." when you use the context menu command "Change Dir" on the ".." entry. Which wasn't related to Lgi and the Mac port, but a bug none-the-less. Now there is a little issue with the saving and restoring of account information in the connect dialog. And after that a little more testing to make sure the basic functionality is working and then I'll release it. I'm also looking for some good documentation on how to build a .dmg to distribute the application. Reeeeeeaally close now :) |
(0) Comments | Add Comment | |
Mac Port Update | |
---|---|
Date: 22/1/2007 | So I've got the scrollbars all sorted out. They paint correctly and work when you click on them. I havn't implemented any sort of mouse capture yet but it's good enough for a beta release.
Then I noticed that the context menus don't work, so I implemented GView::GetMouse and then everything just stopped working. This was because the mouse hook thread was hanging. So I've disabled that for the moment, as it doesn't add any important functionality for a beta release. My current issue with the contextual menus is that when I call ContextualMenuSelect it shows the menu fine, and I can click on an item and it flashes briefly but then it returns userCanceledErr (-128). There must be something I'm not adding to the menu items I guess. I've posted on the carbon dev list about it and hopefully someone will know the answer. Still hoping to scrape in by the end of Jan. |
(0) Comments | Add Comment | |
Mac Port Progress | |
---|---|
Date: 21/1/2007 | I struggled with getting the mouse handling to work at the same time as
resizing the window, but after several hours I've got it sorted. Turns out that I
need to detect the mouse being inside the title bar OR the resize box and
return "not handled" otherwise I need to handle the click and return "no error"
for things like up clicks AND resizing to work correctly. The docs were less
than complete in that regards.
The point of that little diversion was getting the scrollbars working. Initially I thought that I hadn't implemented a native control, but no I had actually already put in place the X-platform control. What was going on was that I hadn't hooked up the layout control to actually ATTACH the scroll bars... yeah ok moving on. So now that is sorted out but I had to fix it crashing when the scrollbar is removed. So now I need to get the scrollbars painting properly... they are all out of alignment with the parent window right now and then maybe things will be ready for packaging. Maybe. I say maybe because everytime I think I'm getting really close I find some other show stopping bug. I think I'll make the first release a zip or something so I don't have to waste more time figuring out .dmg files. Unless they are like 5 minutes of work...? |
(0) Comments | Add Comment | |