ATTENTIONThis FlexSim Community Forum is read-only. Please post any new questions, ideas, or discussions to our new community (we call it Answers) at https://answers.flexsim.com/. Our new Question & Answer site brings a modern, mobile-friendly interface and more focus on getting answers quickly. There are a few differences between how our new Q&A community works vs. a classic, threaded-conversation-style forum like the one below, so be sure to read our Answers Best Practices. |
flexsim.com |
#1
|
||||
|
||||
C++ API Question
I was asked this question and don't know the answer, so thought I may get help from the user community.
Any thoughts? "If we wish to write code in C++ where would we find the API? I’ve noticed there are some header files in the program\system\ide directory but I was hoping there might be something else such as a navigable html compilation (like Javadoc for example)." Thanks .... Kenny |
#2
|
||||
|
||||
main menu option Help > Commands.
Unless otherwise noted in the documentation, all of those commands work in C++ in Flexsim. Plus you have access to the Windows API from C++ in Flexsim. For information about the Windows API, use www.msdn.com. |
The Following User Says Thank You to Phil BoBo For This Useful Post: | ||
Kenny Macleod (06-21-2010) |
#3
|
||||
|
||||
Thanks Phil,
Any guidance on the second part of the question: The person asking me was hoping there might be something else such as a navigable html compilation (like Javadoc for example). Kenny |
#4
|
||||
|
||||
Kenny,
I'm don't know what is meant by a "navigable html compilation" But basically C++ in Flexsim is extremely easy because it is C++. So you can write your model in C++ or you create a seperate DLL and have your own C++ program in there. How to create that DLL is described in the wiki articles on this forum http://www.flexsim.com/community/for...read.php?t=382 And using that DLL is like the reverse from API calls. Now you don't call commands from C++ but you are in C++ and call the Flexsim functions. I would say that 99% of the Flexsim functions can be called from within that DLL. It looks a bit to me that your client is looking at it from a perspective that he knows and doesn't fully understand how Flexsim works. |
The Following User Says Thank You to Steven Hamoen For This Useful Post: | ||
Kenny Macleod (06-23-2010) |
#5
|
||||
|
||||
Thanks Steven, that makes sense. I think I was looking for some kind of interface and thinking it was more complicated than it was.
As for the navigable HTML compliation, I hadn't heard if it either, hopefully some of the Flexsim guys may be able to contribute further. Kenny |
#6
|
|||
|
|||
I think Steven made sense. Your client need to state the end that they want to achieve in the scenario that they wanted to model, and we will show them how Flexsim could achieve that. As we are not Anylogic, therefore we don't the way the they do. But come to modeling we could do based on the model requirement.
Make sense? David
__________________
Advent2 Labs David |
#7
|
||||
|
||||
The Flexsim command documentation is a navigable html compilation. In 4.5, it opened in a web browser. In 5.0, it opens in the User's Manual, which is a chm (compiled html) file.
|
#8
|
||||
|
||||
JavaDoc is just a mechanism where you write special "markup" comments in your source code. These special comments are then automatically compiled into html documentation for the API you are creating. So basically it's a way for you to create the documentation at the same time that you write the source code. Flexsim doesn't use JavaDoc, but it has its own documentation of the "API" through the command list documentation, as Phil mentioned. Flexsim's "API" is really just the command list, and that can be found in a navigable html format in the user manual. For documenting a model, users can use the /** comment syntax to give documentation for a given field, so other modelers can get a synopsis of what the field does, and then that markup text can be exported using the Model Documentation feature. So Flexsim's /** comment mechanism is similar to the JavaDoc mechanism (I think JavaDoc even uses the /** syntax as markup, but I'm not sure).
|
The Following 3 Users Say Thank You to Anthony Johnson For This Useful Post: | ||
Phil BoBo (06-22-2010) |
#10
|
|||
|
|||
Hello all,
Thank you for all the responses to the question Kenny asked on my behalf. I’m merely evaluating the advantages/disadvantages of different simulation packages so it’s difficult to give specific examples of the models that need to be created. I’m just trying to understand the capabilities of Flexsim. I’m aware of the Flexscript command documentation (which is nice) but I was under the impression that Flexscript was a mechanism of exposing a limited set of functionality to the user to enable non-programmers to implement custom behaviour. Then, if more freedom was needed, one could jump into C++ and have full access to Flexsim’s interface. It was mentioned that Flexsim’s source was “open” in a way – you can’t see the implementation of the functions but you can see/have access to the C++ interface (this was the API I was looking for). But I may have misinterpreted this. I’d hoped one of the benefits of jumping to C++ would be you could call functions on objects as opposed to passing all operands as parameters to global functions. E.g. string name = getname(obj); //global function vs. string name = obj.getname(); //member function The former makes code completion a little less useful in that it is always in the same global context. But then I’m sure Flexsim isn’t intended to be a fully functioning C++ IDE so having any code completion at all is nice :] Also, it looks like everything is generally the same type in Flexsim anyway; they all seem to be nodes in a list (?). So, to clarify, any functionality implemented in C++ provides greater performance and allows for custom functionality/external model integration, but the interface to the Flexsim engine and Flexsim objects is still limited to those functions that are already exposed to Flexscript (plus the few extras mentioned in the “Creating DLLs..” thread)? This is probably more than enough for the vast majority of applications. As you can tell I’m still relatively new to Flexsim so I’m still trying to understand the paradigm. Thanks again for your responses so far. Cheers - Joel |
The Following 3 Users Say Thank You to Joel Schmidt For This Useful Post: | ||
Tom David (06-23-2010) |
#11
|
||||
|
||||
Joel,
Yeah, mostly the interface to accessing object functionality is through a set of global functions, not object methods. This is the same for c++ and flexscript, so the transfer from flexscript to c++ involves hardly any code changing. So as you said, the advantage to c++ is mainly just for speed and maybe code hiding if you use a dll (as well as access to some c++ constructs that aren't available to flexscript such as complex arrays, explicit memory allocation/deallocation, etc.) |
The Following User Says Thank You to Anthony Johnson For This Useful Post: | ||
Joel Schmidt (06-27-2010) |
#12
|
|||
|
|||
A note on object methods
Just a quick point on calling the code on the objects which is something I prefer from an object oriented point of view. You can call nodefunction on any node, which allows local code to be called on an object - and this is also how the triggers work. So if you decide you want to be able to call your own 'standard' function on any object and have that code execute something different depending on the equipment type or instance this is what I recommend:
Assume we want to run some procedures to calculate results that are specific to types of equipment, and do it for differing types of objects at the end of the replication. For this I’d create a main global generic function called 'calcresults(obj equipment)' which just uses nodefunction to call code stored on the equipment's variable or label called 'calcresults' ,which you also create. That node then either contains all the code for that function, or itself calls another user function called equipmenttype_calcresults() which has the required code for that type. That way you can call calcresults() and pass in any object irrespective of the type and know that the relevant code for that type of object will be called. You can then also make calcresults unique for an object instance, by having its variable/ label code call equipmenttype_calcresults as normal AND have additional unique code in the node. So the advantages of this structure are: 1) you get to use a the same global function call for all objects 2) You can store generic code for a class of equipment once, instead of entering it onto each instance 3) You can override the code for an instance or combine it with that for the class/type. (a kind of polymorphism as I understand it) Last edited by Jason Lightfoot; 06-26-2010 at 05:18 PM. |
The Following User Says Thank You to Jason Lightfoot For This Useful Post: | ||
Joel Schmidt (06-27-2010) |