_______________________
"im going to continue making this crazy stuff then after a while my style will be so sick that you will be like damn suuun that shit is so sick i dont even get it. i will be like bro its ok.. you dont have to." -omgdonut
Yet again, this looks amazing! Can the dialog resources be used or is it all done from scratch?
I'll change that scrollbar to a pointer, but it's currently unused (other than as a placeholder) so you can as well remove it at the moment. It might get used once zooming is added.
poodlecock: I'm hoping for a release-worthy milestone in a week or so. You want Windows? Linux? OSX?
jsr: Thanks! As far as using the dialog resources is concerned the answer is yes. I have written adapter classes for all of the MFC "dialog widgets". This allows me to have two main "glue code" sections within each of your dialog classes. The first section creates the dialog using the DIALOGEX commands from the FamiTracker.rc as a direct guide. The second section connects up the dialog widgets' Qt signal/slot mechanisms to the MFC command handlers. hyarion is helping write a .rc file parser so that automation of the first part can be achieved -- which will make following along with any MFC updates you make much easier.
For an example of what I just said, take a look at the DPCM instrument pane dialog and its header [note: I'm porting 0.4.1 still]. In the class constructor is the first glue code portion. This will be replaced eventually by a call to hyarion's parser to agnostically parse the IDD_INSTRUMENT_DPCM information from the .rc file--instead of handcoding its reinterpretation. In the header file you see a Qt interfaces portion. Each of those slots is a replacement for the MFC message map, linking "messages" [Qt signals] from those dialog resources to "message handlers" [Qt slots] that then call the MFC handler in the class. It all works very nicely indeed! In fact I only have to implement some nullifying #define's and then I'll be able to leave the message map stuff uncommented -- one less change to make!
I do have a few questions...One that comes to mind now is: I can't figure out how to get to the CChannelsDlg at runtime? It looks like it should be a popup menu option but I can't figure out where it is.
I'm not a programmer, so I can't answer most of your questions, but Fedora Linux or Windows are both fine with me. Thanks!
_______________________
"im going to continue making this crazy stuff then after a while my style will be so sick that you will be like damn suuun that shit is so sick i dont even get it. i will be like bro its ok.. you dont have to." -omgdonut
The CChannelsDlg dialog is still being worked on and isn't available in the released versions, so you can safely ignore that too. It can be accessed from a debug build, but it doesn't do anything.
hatsize7: I run Ubuntu 12.04 in VirtualBox so that will be my Linux build test platform. Unfortunately I completely lack Linux packaging skills...but we'll figure something out.
. Rip out and re-do the originally hacked CMainFrame implementation, now that most major portions of the MFC HLE are in place and working.
Good news: step 1 of the plan is going smoothly for the most part. My MFC HLE is up to 7500 SLOC and contains Qt reimplementations in some form or other of quite a few of the MFC classes (highlighted in yellow).
Bad news: I'm running behind and will not be able to have a release by the end of this week as planned.
In-between news: I'm still working on it! =] Sorry for the delay!
Just a quick note to say I haven't disappeared. The reimplementation of the main frame is taking longer than I'd anticipated and, of course, life is getting in the way. I am gutting my previous hacked-together main frame [which reimplemented the FT main window using pure Qt widgets and layout]. I'm currently in a state where the toolbar buttons don't work [reimplementing CToolBar] so I'm highly motivated to get it back to being able to play songs. After all...most of the motivational energy comes from listening to many of the great tunes you guys come up with. That, and some of the latest postings I've tried downloading indicate they're created with 0.4.2 which is motivation to get my butt in gear and finish the 0.4.1 port so I can get 0.4.2 rolling!
Many apologies to those waiting for me to have been done weeks ago as I initially thought!
Nice to know you haven't given up, cpow! Good luck with your port!
Also,
cpow wrote:
I'm highly motivated to get it back to being able to play songs.
That's what NSF players are for. Anything you want NSFs of, please let me know and I'll make an NSF for it.
_______________________
"im going to continue making this crazy stuff then after a while my style will be so sick that you will be like damn suuun that shit is so sick i dont even get it. i will be like bro its ok.. you dont have to." -omgdonut
Hi poodlecock. Thanks! I meant that it's motivational listening to the tunes in their native tracker form since it also helps me make sure I haven't dorked anything in my port. Fairly soon I should be able to export my own NSFs from this thing. =]
I've got a few changes I'd like to get pushed upstream to make future migrations from MFC versions easier.
The first is a blanket header file lower-caseing in #includes. This is preferred for Linux builds and doesn't break Windows.
The second is in the file ChunkRender.cpp there are various places where CString objects are passed as arguments to variadics. Apparently this "works" in MFC because the first 32-bits of the CString object is actually the character string pointer so the variadic just magically "works". But in Qt I get "cannot pass non-POD type through ...". The easiest thing do to is just put (LPCTSTR) casts on each CString object passed in this way. That way I don't have to play some games to make something that "works" in MFC work when it really shouldn't work.
Hi, is it important that #includes are lower-case or is it enough if it's matching the actual files?
I think I understand the second problem. Actually there seems to be a note about this in MSDN also (I just checked), so I'm gonna have to fix this. I always assumed there was an implicit conversion or something, I never thought about why it actually worked. Thanks for letting me know.
.png)
