Open ptxmac opened 1 year ago
I'd say this is not necessary. We could easily create a one based on basic drag int or float.
Mess with pointer data via CGO is not that pleasant after all.
Mess with pointer data via CGO is not that pleasant after all.
agreed, but for certain applications the loss of precision when converting between float and double is unacceptable.
we could create DragDouble
instead of switching in DragScalar
, but then we should probably also create the rest of the supported datatypes: signed and unsigned 8/16/32/ 64 bit integers
@AllenDang I think we can make our wrappers public to make *Scalar functions easier to use
@ptxmac from current code:
// InputScalarV parameter default value hint:
// p_step: NULL
// p_step_fast: NULL
// format: NULL
// flags: 0
func InputScalarV(label string, data_type DataType, p_data unsafe.Pointer, p_step unsafe.Pointer, p_step_fast unsafe.Pointer, format string, flags InputTextFl
labelArg, labelFin := WrapString(label)
formatArg, formatFin := WrapString(format)
defer func() {
labelFin()
formatFin()
}()
return C.igInputScalar(labelArg, C.ImGuiDataType(data_type), (p_data), (p_step), (p_step_fast), formatArg, C.ImGuiInputTextFlags(flags)) == C.bool(tru
}
So I suppose its fixed
It looks like this has been broken again, now the code is uintptr
instead of a real pointer
@ptxmac what's wrong with it?
The code gen doesn't see the value as a pointer, so it's never copied.
Current code:
func InputScalar(label string, data_type DataType, p_data uintptr) bool {
labelArg, labelFin := datautils.WrapString[C.char](label)
defer func() {
labelFin()
}()
return C.wrap_igInputScalar(labelArg, C.ImGuiDataType(data_type), C.uintptr_t(p_data)) == C.bool(true)
}
It should be similar to InputInt
:
func InputInt(label string, v *int32) bool {
labelArg, labelFin := datautils.WrapString[C.char](label)
vArg, vFin := datautils.WrapNumberPtr[C.int, int32](v)
defer func() {
labelFin()
vFin()
}()
return C.wrap_igInputInt(labelArg, vArg) == C.bool(true)
}
But where the type of v
depends on the data_type
argument.
Basically the fix mentioned in https://github.com/AllenDang/cimgui-go/issues/74#issuecomment-1709000875 have regressed and we're back to the original problem
yeah. I think there were a problem with -race
maybe... let me reopen that and thats all I can do for now (i'm working on my other project atm)
I was looking for a
DragDouble
widget, but imgui has been implementing new datatypes using the*Scalar
widgets instead.These work just like
DragInt/Float/Etc
but takes an enum declaring the type and a void pointer to the data.For this to work from go we need a way to manually wrap the go pointer, i.e. make
wrapNumberPtr
public.Or perhaps implement
DragScalar
with a switch that will type-cast based on the DataType.something like: