Skip to content

Conversation

@LB--
Copy link
Contributor

@LB-- LB-- commented Mar 17, 2014

This is a follow-up to #14 which can't be reopened now that it has been closed. I have dramatically updated EDIF in many ways - there is too much to list. Let me know if anything needs changing before this PR can be accepted.

This includes #17 and #18 in it.

I've also started adding helpful info to the wiki in this repository.

LB-- added 30 commits October 20, 2012 00:42
I did this one without access to any compiler - will have to check if it works later.
BuildSettings.vsprops applies to all build configurations and currently
defines the MFX_Name macro (default "Template.mfx"), which can be
changed in this one file to reflect among all the build configurations.
The message displayed when inserting an EDIF extension named
Template.mfx now includes proper instructions for renaming the MFX. In
the project tree view, ObjectSelection.h/.cpp are in a Riggs folder now
(based on the namespace they are in).
I need to find a way to have it be automated...
It shows the name of the extension from the JSON in the dialog titlebar.
LB-- added 30 commits May 25, 2015 16:35
It keeps getting changed and I have to try random numbers until I find
it.
I hate the C++ iostreams library. It is the worst designed library I
have ever used and it never ceases to cause me pain. I have no idea why
sync() never gets called. I have no idea why the tutorial I followed
told me to return a failure code on success in overflow(). I have no
idea why I thought it would still work properly with wide streams. But I
do know this: I need to rip out this iostreams stuff next time I get a
chance, and got with a simple vector buffer instead. Nobody needs the
iostreams stuff.
Yes I know this is bikeshedding. It was bothering me and it's better than nothing.
Looks like `copy` was being leaked. To be honest I'm not even sure why a
copy needs to be made here, but I assume it's for a good reason so I
made the minimal fix necessary. It's not a performance concern anyway.
Thanks to VC++'s Code Analysis for finding the sketchiness.
Apparently the MMF2 editor will load the Edittime HWA MFX but unless you change the display mode from Standard to one of the hardware accelerated modes, it needs a non-HWA MFX to be able to run the application. Makes sense, but adds so many more build variants...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants