Maybe no one's noticed this but undo/redo operations are seriously f'cked up. Maybe it's due to a limit on the number of changes kept track of, I don't know. My memory may fail me, but in the past I think it's processed changes between modules in module-agnostic order rather than by the module currently being edited. It definitely has limitations and leaves the code in a mixed state when moving back and forth through the history a certain number of times.
Sorry for the vague info about it, as I'm not sure exactly what it's doing, but it definitely needs a second look. At some point the undo/redo operations just stop with the code in a random state within the history. My suggestions are to have a large default history, and to keep separate histories per module. Maybe having the changes itemized, browsable and editable would be good, something like an integrated version control system. No biggie, just some ideas for after gb3.0 is released. -- Kevin Fishburne Eight Virtues www: http://sales.eightvirtues.com e-mail: sa...@eightvirtues.com phone: (770) 853-6271 ------------------------------------------------------------------------------ AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on "Lean Startup Secrets Revealed." This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev _______________________________________________ Gambas-user mailing list Gambas-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gambas-user
