Everytime when I use Jucer, the tool generate “setSize (…);” code in the end of constructor, and next line has following comments
//[Constructor] You can add your own custom stuff here…
//[/Constructor]
resized(…) also has almost same comments in the end of the function.
//[UserResized] Add your own custom resize handling here…
//[/UserResized]
For example: if I try to add Drag&Drop function, I have to add my code in the middle of the commants, but I got a segmentation fault.
but, if I move my code before the setSize (…) API calling like following.
//[Constructor] You can add your own custom stuff here..
addAndMakeVisible (dragSource = new DragAndDropSource ());
printf("DEBUG1\n");
//[/Constructor]
setSize (992, 600);
It is fine.
The problem happens some cases. some components are no problem what ever I add my code before setSize(…) or after setSize(…).
and the segmentation fault always occurs in added function inside resized(…).
do you know the reason ? if I always keep the sequence, you need to change Jucer code.
You’re obviously just using uninitialised pointers in the resize callback, before the objects have been created. Are you still not using a debugger?
I guess it’d be useful to have another user code section before the setSize call, but if your “DragAndDropSource” is a component, why not do it as a generic component in the jucer, and let the jucer create its construction code?
It means that User code should be initialized before setSize to avoid calling of uninitialized pointers in resize callback in my understanding.
To avoide the bad situation, as you mentioned, making user code section before the setSize call is the best becasue general S/W developer dosen’t need to think more to find uninitialized pointer after he got problem.
he just need to follow your guid line , which generated from jucer, to fill up some user code in defineded user section.
Yesterday, after I wrote a message, I found that jucer can create construction code, then I am using the way for Component.
Regarding my debugger, I am in trouble to use GDB. Is there anybody to solve this problem ?
my condition:
I have to use general Cygwin Environment because I have to build Linux/Unix/Posix compatable code to share with Linux/my Embedded Target/Win32 environment every produced results include Makefile.
then, I use only Posix Compatable APIs and limited grammer rule to make 100% compatable code between different environments.
I can’t use graphical IDE interface like DEV-C++ because it use MINGW and it dosn’t have some Linux/Posix API like “gettimeofday” and so on…
I have to use -mwindows option in compiling to make Win32 application.
this is the problem point, if I don’t use this option in Cygwin, GDB is workingn well, but including this option, GDB works like madman.
this is for only Win32 and it is minimum changing points ( only 2 files ) to support different environments, but I use this environment for almost develeloping. this is my dilemma point whether I move to linux environment to use GDB.
In case of graphical IDE interface, it can provide importing general Cygwin environment, if I choose the option, It works like #3 case.
then, who knows the solution for this problem ?
IDE interface to use full Cygwin environment. not MINGW
Cygwin environment with GDB including -mwindows option.
The whole point of Juce is that it’s cross-platform, so why not develop it as a win32 app in VCExpress, and then when your code works, just recompile it with cygwin to see if it’s still ok?
Really - Jules is right (and being suspiciously polite). I work on XCode, cross to VC++ Express. There’s usually about 2-3 compiler warnings and 2-3 linker warnings, and very rarely an extra runtime error. In fact using the two systems catches more bugs.
Working without access to a debugger is madness, especially considering Juce’s strength is the cross-platform zing. You will save far more time, and posts, by working in a decent environment then re-checking in your target environment.
I totally agree with your opinion if I worked in general application environment like you.
In the embedded area, that is different story. if you make same function in PC and if you use different code in target device, nobody believe that It will make same result in embedded system. Logically, if you made same function, it should do same action in embedded device as well, even though you used different code, but human mistake makes that Nobody believe the code, and embedded area is more sensitive for error.
because of that reason, embedded S/W engineers love to use only printf(…) function for their debugging and they don’t come to PC area to make same code like me. even my case is much progressive approaching to simulate same function in PC with same compiler and with same sources.
For example : GCC/MSVC compiler automatically fill off inital data ‘0’ for uninitialize variables. but VxWorks compiler dosen’t do that.
this kind of small different can impact to embedded S/W developer’s behavior not to use debugger and not to use simulating environment in PC. there are many reasons why embedded S/W engineer dosn’t use debugger like because interrupt relevant operation or time critical operation…
but, In my case, I compromized that by seperating real low level operation and high level operation in our S/W architecture to take advantage of PC developing environment, and I have cut off all Xcode/Assemble code/MSVC code/name space and so on… to make only one code for posix compliant code, and it works on Cygwin environment. that is why I want to use GDB in Cygwin environment with -mwindow option, but Investigating current many solutions as far as I can do, there is no solution.
further more, I don’t like to install VC++ in my PC and VC++ can’t make excutable file with my modified posix compliant sources, and I made my own windows system for target device. that is also simulated in Cygwin environment. I don’t want to move that In heavy VC++ and different style of Makefile and project file.
I just want to keep only one way from PC simulation to Linux(it is also one of simulation) and lastly to Target device.
Keeping Cygwin environment with Cywin/X11 simulation.
In this case, application dosn’t need to include -mwindows option. so I can use gdb console, but little strange thing in here is that DDD is not working properly to high light breakpoint.
Recently, MINGW increased supporting features, and it can be adoptable by using Code::Blocks, If I can successfuly migrate current sources to the environment, I will get a great WISWIG debugger…
DEV-C++ is not updating now, but Code::Blocks is very active and I discussed this issue with the main developer who told me no plan to support Cygwin environment because Cygwin mess up signaling and somthings… but MINGW is not…
Keeping Cygwin environment with Cywin/X11 simulation.
In this case, application dosn’t need to include -mwindows option. so I can use gdb console, but little strange thing in here is that DDD is not working properly to high light breakpoint.
Recently, MINGW increased supporting features, and it can be adoptable by using Code::Blocks, If I can successfuly migrate current sources to the environment, I will get a great WISWIG debugger…
DEV-C++ is not updating now, but Code::Blocks is very active and I discussed this issue with the main developer who told me no plan to support Cygwin environment because Cygwin mess up signaling and somthings… but MINGW is not…
