# How to define an entry point when using \`paraview\_client\_add\`?
**URL:** https://discourse.paraview.org/t/how-to-define-an-entry-point-when-using-paraview-client-add/17378
**Category:** Development
**Tags:** qt
**Created:** [December 15, 2025, 9:07am UTC](https://discourse.paraview.org/t/how-to-define-an-entry-point-when-using-paraview-client-add/17378 "2025-12-15T09:07:27Z")
**Posts on this page:** 3
**Page:** 1
### Author:  [@CsatiZoltan](https://discourse.paraview.org/u/CsatiZoltan)
#### Post date: [December 15, 2025, 9:07am UTC](https://discourse.paraview.org/t/how-to-define-an-entry-point-when-using-paraview-client-add/17378/1 "2025-12-15T09:07:28Z")
I would like to make ParaView accept custom command line arguments in my ParaView custom application. To achieve that, I want to pass the optional argument of type `vtkCLIOptions*` to the `pqPVApplicationCore` constructor.
You can do so by [explicitly instantiating `pqPVApplicationCore`](https://gitlab.kitware.com/paraview/paraview/-/blob/b166fde23a2f90ec04662ae7f975283ebbe60135/Examples/CustomApplications/Demo2/DemoApp2.cxx#L13), as done in the Demo2 example. Then you have to write your own entry point `int main(...)`. The Demo2 example manually creates the executable using the [`add_executable`](https://gitlab.kitware.com/paraview/paraview/-/blob/b166fde23a2f90ec04662ae7f975283ebbe60135/Examples/CustomApplications/Demo2/CMakeLists.txt#L29) CMake command. The more complex custom applications, such as the _SimpleParaView_ example or _LidarView_ rather use the CMake macro [`paraview_client_add`](https://gitlab.kitware.com/paraview/paraview/-/blob/b166fde23a2f90ec04662ae7f975283ebbe60135/Examples/CustomApplications/SimpleParaView/client/CMakeLists.txt#L13). In this case, the entry point is in the autogenerated file. How can I pass a custom entry point (in the Demo2 example, it is [DemoApp2.cxx](https://gitlab.kitware.com/paraview/paraview/-/blob/b166fde23a2f90ec04662ae7f975283ebbe60135/Examples/CustomApplications/Demo2/DemoApp2.cxx) to `paraview_client_add`?
I read the following in the [changelog](https://gitlab.kitware.com/paraview/paraview/-/blob/master/Documentation/release/ParaView-5.10.0.md#changes-for-developers):
> Custom applications can easily add their own `*Configuration` classes to populate `vtkCLIOptions` to custom options or override the default ParaView ones. If your custom code was simply checking user selections from `vtkPVOptions` or subclasses, change it to using the corresponding `*Configuration` singleton
Is there an example out there ?
---
### Author:  [@mick76](https://discourse.paraview.org/u/mick76)
#### Post date: [January 2, 2026, 8:56am UTC](https://discourse.paraview.org/t/how-to-define-an-entry-point-when-using-paraview-client-add/17378/2 "2026-01-02T08:56:30Z")
you can’t pass a custom `main()` to `paraview_client_add`. that macro always generates its own entry point, so files like `DemoApp2.cxx` won’t be used.
the way that works is:
don’t own `main()`
1. subclass `vtkCLIOptionsConfiguration`
2. register it so ParaView picks it up before `pqPVApplicationCore` is created
3. add/override CLI options there
that’s what the changelog refers to. if you need full control over the entry point, you have to skip `paraview_client_add` and use `add_executable` instead.
---
### Author:  [@CsatiZoltan](https://discourse.paraview.org/u/CsatiZoltan)
#### Post date: [January 2, 2026, 9:02am UTC](https://discourse.paraview.org/t/how-to-define-an-entry-point-when-using-paraview-client-add/17378/3 "2026-01-02T09:02:06Z")
Thank you. How can I implement step 2, i.e. registering it for ParaView?