Do you think that it would be feasible to compile the project in the last version of delphi, XE5? Due to the multiplatform support, I think it would be really nice!
Thanks,
Max
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually I have just got my XE5 on the last day of promotion (and how I will pay my rent is another question) and the migration will start as soon as I validate and check in the last modifications, most likely this weekend. But I am not sure if it actually will contribute to multiplatform builds if you mean Mac as the code is based on VCL and Microsoft COM but the 64 bit build is possible once the dependence on the ProGrammar library is removed.
Last edit: Janusz Szpilewski 2014-02-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Great news Janusz! I am not a dragon in Delphi, as you know, but if you need any kind of help please let me know. For the moment I succeeded in installing the latest JEDI libraries in XE5 (fortunately they updated it), now I will check all the other necessary libraries... I think I still miss the Virtual TreeView and Toobar2000 + TBSkin.. and who knows how XE5 will behave
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Jan,
I am allmost there, I have just an issue with the dxGDIPlusAPI.
Just one hint, as I found it today, some global variables in in System.SysUtils have been removed, therefore access them via FormatSettings.* and it will be OK (it's with the plastic component).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually the executable I get - in release mode - is 27 Mb... in Debug is 52...
Do you think this is normal for XE5 or there's something wrong?
The first time I compile it anyway it runs, but if I try a second time.. it crashes..
Anyway, for today I did some good at least
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
after the first compile the PaletteNavBar in the MainFrm changes, showing all sections (Annotation, Class, etc.) and if I compile it that way, it does not work (EListError behind the corner...).
The old trick of deleting it from the form and then drag it from standard forms does not seem to work as it says there are no defined frames to insert...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well, bad luck with that PaletteNavBar. I remember seeing it work in XE3 so I hope it can be fixed. Also I noticed that the executable in XE3 was bigger, something about 12 MB in the Release mode. Let's hope that XE5 does not get gratuitously so bad.
Personally I noticed another problem with PaletteNavBar. When the program window is small and the palette shows the scrollbar it starts misbehaving. When you scroll down, select and use an item (like Realization) by default the palette scrolls up and the Select item gets active. And if you next hover the mouse over palette there is some misfitting between the cursor position and the highlighted item on the palette. I tried simple refresh commands and it does not help. I suppose this may be a bug in the TCategoryButtons component and with some luck fixed in XE5. So probably I will give up on this till the upgrade.
So if you were so lucky and manage to get the palette to work you could check if there is still some similar behaviour when the program window is small and the palette shows a scrollbar.
Last edit: Janusz Szpilewski 2014-02-07
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I cannot reproduce the bug you mentioned, so hopefully this was fixed.
Please let me know how you go on with your compile, if you have a big exe file as well and how do you go with the PaletteNavBar...
meanwhile I will try and fix this.
Best
Max
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
succesfully substituted with NavBarFrameTdxImpl and compiled... but the executable crashes :(
Trying to understand all the abstractions and the frame concept you introduced in comparison with direct usage of TdxNavBar in StarUML but I am afraid I am getting lost :P
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am aware that all glitches with navigation panel are related to the usage of visual inheritance that is somehow staggering there. However the biggest advantage of using it is that it splits the code into separate parts that are dependent and not on the actual navigation component being used. Hence the external code is not aware of it and it is possible to swap different implementations (like TCategoryButtons and TdxNavBar)with drag & drop. I am still hoping that at some point Deplphi will reach the state when all such glitches will be gone.
NavBarFrameTdxImpl is not complete. It misses implementation of some code integrating it with the program so it may be crashing. I have just checked-in all sources and will publish the last Delphi 2010 build next. After that will start the migration myself.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ok Jan,
thanks.. indeed being able to swap components that way is really nice.
if you intend to complete the Tdx, please let me know.. i'd like to use the DevExpress libraries I have, even if I am not sure my version is 100% compatible with XE5.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
TdxNavBar is not evolving rapidly I think. It is rarely mentioned in DevExpress updates so I think the older versions may still work. I think that the missing part from the Tdx based panel is creation of the wrappers for navigation groups and elements called from CreateNavBarGroup() during panel initialization. Doing it may be quite messy and requires good knowledge of TdxNavBar but if are interested you may try. I do not own TdxNavBar so I cannot test it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Jan, otherwise I shall try to revert back to the original approach without the parent frame. For category buttons still no skin or themese, right?
I think I have seen an example with some customization, but it was on a chinese website, so I did not get the changes.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
WorkingAreaDockPanel is of type TdxDockPanel which is a class in the ExpressBars component suite from DevExpress. And indeed every definition of a dock panel contains a line like:
CustomCaptionButtons.Buttons = <>
Normally I am working with the latest version of DevExpress components which are now at version 13.2.5. You may happen to have an older version. If it is still a recent version you may just try to delete that line from MainFrm.dfm which looks to be empty anyway.
One more hint, if you are successful with that to avoid problems with the navigation panel keep the main form (MainFrm.pas) closed when compiling and running the program.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
thank you.
You are right, I have an older version. Getting rid of that part by Ignoring the errors I was able to open mainfrm and compile the project.
I have now a very difficult error to spot out. Every time I create an element in the diagram I get a Violation Access error.
Using the .map and the address of the error, I could identify the problem relying on the ModelExplorerFrame unit.. it seems like the part that associate the images (using indexes in vectors) to the elements points to areas of the memory where there's no image and therefore the error... do you have any idea?
I did not change any line of code except what you told me, so I would expect this to work..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also had problems with the Model Explorer using Virtual TreeView version 5.2 or newer. So the latest working one is 5.1.3 as mentioned in the README file. Anyway your observation may be useful to track what is the problem with the newer versions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
interesting.. I have now downloaded Virtual TreeView 5.1.3, substituted the bpl using the XE4 version of 5.1.3 and re-compiled, but I am getting the same Violation access error..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am using VTV 5.1.3 compiled from XE4 config too. Can you post the exact line that is crashing? As I remember in my case it was a callback in the Model Explorer code called from Virtual TreeView.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
my fault, I left the 5.3 also in the library path (used add and not replace).
While I was checking the memory access issue, I noticed the functions change time by time. It might be hard to point out the glitch, but I noticed something have been done on the ModelExplorerFrame in comparison with some previous version (I guess).
I can see the following comment on top:
while modifing to Virtual Treeview, Tree's Node is changed from TObject
// to pointer of record. Because Objects in NodeHashTable must be not Object
// but Pointer, Pointer is casted to TObject.
Could it be related to the cast?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am glad it works now. The pointed comment comes from the original StarUML developers so I think it does not affect the recent code. Since then the file ModelExplorerFrame.pas passed a few modifications but generally the interaction with VTV was unchanged. So I think the problem shows up after some evolution in VTV.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am sure it's related to some evolution in VTV, but this means we should probably use the ModelExplorer nodes differently.
I am not anymore sure if the issue is related to the images or generally the nodes and their management in memory. I think it won't be easy to find a way to fix it, unless we find some other use case scenario with the newest versions that get the same memory issue. I actually googled it and there are many case, but all very specific.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
as I had to delete some parts of the code, in the future I would like to keep this source separate from the SVN, otherwise every update I need to amend it.
Do you have any preferred way of Source Control to maintain 2 separate instances of the same project? if you update something I would like anyway to see what you updated.. Is there any more intelligent way than checking each single .pas one by one?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Hi Jan,
Do you think that it would be feasible to compile the project in the last version of delphi, XE5? Due to the multiplatform support, I think it would be really nice!
Thanks,
Max
Actually I have just got my XE5 on the last day of promotion (and how I will pay my rent is another question) and the migration will start as soon as I validate and check in the last modifications, most likely this weekend. But I am not sure if it actually will contribute to multiplatform builds if you mean Mac as the code is based on VCL and Microsoft COM but the 64 bit build is possible once the dependence on the ProGrammar library is removed.
Last edit: Janusz Szpilewski 2014-02-07
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Great news Janusz! I am not a dragon in Delphi, as you know, but if you need any kind of help please let me know. For the moment I succeeded in installing the latest JEDI libraries in XE5 (fortunately they updated it), now I will check all the other necessary libraries... I think I still miss the Virtual TreeView and Toobar2000 + TBSkin.. and who knows how XE5 will behave
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Hi Jan,
I am allmost there, I have just an issue with the dxGDIPlusAPI.
Just one hint, as I found it today, some global variables in in System.SysUtils have been removed, therefore access them via FormatSettings.* and it will be OK (it's with the plastic component).
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Compiled! now the least is done :P
Actually the executable I get - in release mode - is 27 Mb... in Debug is 52...
Do you think this is normal for XE5 or there's something wrong?
The first time I compile it anyway it runs, but if I try a second time.. it crashes..
Anyway, for today I did some good at least
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
I see... again the PaletteNavBarFrame >:(
after the first compile the PaletteNavBar in the MainFrm changes, showing all sections (Annotation, Class, etc.) and if I compile it that way, it does not work (EListError behind the corner...).
The old trick of deleting it from the form and then drag it from standard forms does not seem to work as it says there are no defined frames to insert...
Well, bad luck with that PaletteNavBar. I remember seeing it work in XE3 so I hope it can be fixed. Also I noticed that the executable in XE3 was bigger, something about 12 MB in the Release mode. Let's hope that XE5 does not get gratuitously so bad.
Personally I noticed another problem with PaletteNavBar. When the program window is small and the palette shows the scrollbar it starts misbehaving. When you scroll down, select and use an item (like Realization) by default the palette scrolls up and the Select item gets active. And if you next hover the mouse over palette there is some misfitting between the cursor position and the highlighted item on the palette. I tried simple refresh commands and it does not help. I suppose this may be a bug in the TCategoryButtons component and with some luck fixed in XE5. So probably I will give up on this till the upgrade.
So if you were so lucky and manage to get the palette to work you could check if there is still some similar behaviour when the program window is small and the palette shows a scrollbar.
Last edit: Janusz Szpilewski 2014-02-07
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Hi Jan,
I cannot reproduce the bug you mentioned, so hopefully this was fixed.
Please let me know how you go on with your compile, if you have a big exe file as well and how do you go with the PaletteNavBar...
meanwhile I will try and fix this.
Best
Max
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Hi Jan,
the problem with the NavBar can be solved getting rid of the inheritance.
Do you still have the old TdxNavBar version?
Max
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
succesfully substituted with NavBarFrameTdxImpl and compiled... but the executable crashes :(
Trying to understand all the abstractions and the frame concept you introduced in comparison with direct usage of TdxNavBar in StarUML but I am afraid I am getting lost :P
I am aware that all glitches with navigation panel are related to the usage of visual inheritance that is somehow staggering there. However the biggest advantage of using it is that it splits the code into separate parts that are dependent and not on the actual navigation component being used. Hence the external code is not aware of it and it is possible to swap different implementations (like TCategoryButtons and TdxNavBar)with drag & drop. I am still hoping that at some point Deplphi will reach the state when all such glitches will be gone.
NavBarFrameTdxImpl is not complete. It misses implementation of some code integrating it with the program so it may be crashing. I have just checked-in all sources and will publish the last Delphi 2010 build next. After that will start the migration myself.
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Ok Jan,
thanks.. indeed being able to swap components that way is really nice.
if you intend to complete the Tdx, please let me know.. i'd like to use the DevExpress libraries I have, even if I am not sure my version is 100% compatible with XE5.
TdxNavBar is not evolving rapidly I think. It is rarely mentioned in DevExpress updates so I think the older versions may still work. I think that the missing part from the Tdx based panel is creation of the wrappers for navigation groups and elements called from CreateNavBarGroup() during panel initialization. Doing it may be quite messy and requires good knowledge of TdxNavBar but if are interested you may try. I do not own TdxNavBar so I cannot test it.
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Thanks Jan, otherwise I shall try to revert back to the original approach without the parent frame. For category buttons still no skin or themese, right?
I think I have seen an example with some customization, but it was on a chinese website, so I did not get the changes.
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
hello,
i tried to compile last version, but as soon as I load the files I am getting the following error:
Error reading WorkingAreaDockPanel.CustomCaptionButtons.Buttons: Property CustomCaptionButtons.Buttons does not exist.
Seems related to the MainFrm, so it is not opened.
Any idea?
thank you
WorkingAreaDockPanel is of type TdxDockPanel which is a class in the ExpressBars component suite from DevExpress. And indeed every definition of a dock panel contains a line like:
CustomCaptionButtons.Buttons = <>
Normally I am working with the latest version of DevExpress components which are now at version 13.2.5. You may happen to have an older version. If it is still a recent version you may just try to delete that line from MainFrm.dfm which looks to be empty anyway.
One more hint, if you are successful with that to avoid problems with the navigation panel keep the main form (MainFrm.pas) closed when compiling and running the program.
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
Hi,
thank you.
You are right, I have an older version. Getting rid of that part by Ignoring the errors I was able to open mainfrm and compile the project.
I have now a very difficult error to spot out. Every time I create an element in the diagram I get a Violation Access error.
Using the .map and the address of the error, I could identify the problem relying on the ModelExplorerFrame unit.. it seems like the part that associate the images (using indexes in vectors) to the elements points to areas of the memory where there's no image and therefore the error... do you have any idea?
I did not change any line of code except what you told me, so I would expect this to work..
I also had problems with the Model Explorer using Virtual TreeView version 5.2 or newer. So the latest working one is 5.1.3 as mentioned in the README file. Anyway your observation may be useful to track what is the problem with the newer versions.
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
interesting.. I have now downloaded Virtual TreeView 5.1.3, substituted the bpl using the XE4 version of 5.1.3 and re-compiled, but I am getting the same Violation access error..
I am using VTV 5.1.3 compiled from XE4 config too. Can you post the exact line that is crashing? As I remember in my case it was a callback in the Model Explorer code called from Virtual TreeView.
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
my fault, I left the 5.3 also in the library path (used add and not replace).
While I was checking the memory access issue, I noticed the functions change time by time. It might be hard to point out the glitch, but I noticed something have been done on the ModelExplorerFrame in comparison with some previous version (I guess).
I can see the following comment on top:
while modifing to Virtual Treeview, Tree's Node is changed from TObject
// to pointer of record. Because Objects in NodeHashTable must be not Object
// but Pointer, Pointer is casted to TObject.
Could it be related to the cast?
I am glad it works now. The pointed comment comes from the original StarUML developers so I think it does not affect the recent code. Since then the file ModelExplorerFrame.pas passed a few modifications but generally the interaction with VTV was unchanged. So I think the problem shows up after some evolution in VTV.
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
I am sure it's related to some evolution in VTV, but this means we should probably use the ModelExplorer nodes differently.
I am not anymore sure if the issue is related to the images or generally the nodes and their management in memory. I think it won't be easy to find a way to fix it, unless we find some other use case scenario with the newest versions that get the same memory issue. I actually googled it and there are many case, but all very specific.
View and moderate all "General Discussion" comments posted by this user
Mark all as spam, and block user from posting to "Discussion"
as I had to delete some parts of the code, in the future I would like to keep this source separate from the SVN, otherwise every update I need to amend it.
Do you have any preferred way of Source Control to maintain 2 separate instances of the same project? if you update something I would like anyway to see what you updated.. Is there any more intelligent way than checking each single .pas one by one?
SVN has such functions like branching and merging and tracking changes with "show log" so having a separate branch should not be a complicated task.