Chris,
in the 3.11 branch "help-doc" is the only argument that calls
SetHidden(), so you could hard code that for now, or use the workaround
of defining the struct GDALAlgorithmArgHS
For 3.12, I've exposed GDALAlgorithmArgIsHidden() in
https://github.com/OSGeo/gdal/pull/12890, and rationalized the naming in
renaming IsOnlyForCLI() as IsHiddenForAPI(), so that IsHidden() ==
IsHiddenForCLI() && IsHiddenForAPI()
Even
Le 07/08/2025 à 16:22, Chris Toney a écrit :
Even,
Got it, thanks.
I'm thinking of the case analogous to GDALDataset, OGRGeometry and
others that have a fromHandle() method. That is occasionally helpful,
when we use primarily the C APIs but there is some public C++ method
not exposed in C that we want to use (i.e., "public" via gdal_priv.h
in the case of dataset). But yeah a workaround there too, not needed
often.
WIth GDALAlgorithmArg there is a "hidden" flag that can be accessed
with GDALAlgorithmArg::IsHidden(). It seems to to mean the arg is
hidden in both CLI and non-CLI "application" contexts, i.e., should
not be given as a user option in either context? In the C API there is
GDALAlgorithmArgIsHiddenForCLI() and GDALAlgorithmArgIsOnlyForCLI(),
but with those I can't tell for sure if the arg should be hidden
either way (e.g., "help-doc" but potentially others it looks like).
Chris
On Thu, Aug 7, 2025 at 2:56 AM Even Rouault <even.roua...@spatialys.com> wrote:
Chris,
why would you need it to be exposed ? If it is to workaround missing C
API entry points, we should add them
Regarding struct GDALAlgorithmHS being exposed in gdalalgorithm.h, this
is because another GDAL .cpp file needed it, but I think I should create
instead a gdalalgorithm_priv.h header to move those struct definitions.
Please don't rely on the internals of struct GDALAlgorithmHS
Even
Le 07/08/2025 à 06:44, Chris Toney a écrit :
Hi Even,
If you need this in 3.11, you can define the following implementation
detail in your code
struct GDALAlgorithmArgHS
Could GDALAlgorithmArgHS be defined in gdalalgorithm.h (as struct
GDALAlgorithmHS is)?
Chris
On Mon, Aug 4, 2025 at 2:42 AM Even Rouault <even.roua...@spatialys.com> wrote:
Hi Chris,
This was indeed missing in the C API. Queued for 3.12 in
https://github.com/OSGeo/gdal/pull/12853
If you need this in 3.11, you can define the following implementation
detail in your code
struct GDALAlgorithmArgHS
{
GDALAlgorithmArg *ptr = nullptr;
explicit GDALAlgorithmArgHS(GDALAlgorithmArg *arg) : ptr(arg)
{
}
};
but better conditionalize it to 3.11 only, so that to avoid issues in
later version if we would change the definition of struct GDALAlgorithmArgHS
and then do things like
GDALAlgorithmArgH hArg;
hArg->ptr->GetDefault<std::string>();
Even
Le 04/08/2025 à 03:46, Chris Toney via gdal-dev a écrit :
Hi,
In the C API there is GDALAlgorithmArgHasDefaultValue(), but no
interface to the GetDefault() class method to access the value itself
when there is one (nor in the Python bindings, AFAICS).
I don't believe there is a fromHandle() method on GDALAlgorithmArg to
get to the C++ object.
Is there possibly a workaround for that when working through the C API?
Chris
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
--
http://www.spatialys.com
My software is free, but my time generally not.
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
