使用Gtk +,我们会通过gtk_image_new_from_file()
将一些图标引入到应用中。我们发现,如果图标文件直接在应用程序目录中,那么这一切都适用于"没有路径",例如。
FString255 = "Icon_Charts.png"
IconImage_Ptr = gtk_image_new_from_file( Trim(FString255)//c_Null_Char )
然而,当我们试图将图标移动到子目录时(多么令人惊讶,称为"图标"),我们无法让Gtk识别png。我们尝试了使用绝对和相对变化我们可以想到的每个排列(例如使用"。\"使用" ./",使用"双斜线",使用" C:..... \ Icons ..."等等......)没有快乐。
是否有人知道Gtk期望的相对路径的语法,例如类似的东西:
FString255 = ".\Icons\Icon_Charts.png"
???
或许有什么东西"特别"关于gtk_image_new_from_file()
,也许它只能接受"没有路径"文件名?
我们感觉它一定是超级简单的东西,我们错过了。
答案 0 :(得分:0)
为避免任何非显而易见的行为,您应始终使用绝对路径。
GLib提供g_win32_get_package_installation_directory_of_module()
函数以允许获取当前项目的路径(假设标准目录布局)。例如:
char *path, *package_dir;
package_dir = g_win32_get_package_installation_directory_of_module (NULL);
g_assert (package_dir != NULL);
path = g_build_filename (package_dir, "Icons", "Icon_Charts.png", NULL);
g_free (package_dir);
答案 1 :(得分:0)
好的,怀疑它,我们感到非常愚蠢和尴尬。我们的OP怀疑:
“我们感觉它必须是我们错过的超级简单的东西。”
......好吧,那是: - (。
在“实际回答”之前,如果真正的问题不完全是其他问题,那么TingPing的回答将是可能的。然而,即便如此,如果我们要走这条路,我们会使用类似的东西(保持我们提交的“与Fortran一致”的OP):
Temp_cPtr = g_get_current_dir_utf8 ()
!
If( c_Associated(Temp_cPtr) ) Then
!
!
n = c_StrLen( Temp_cPtr )
!
FString255Path = ""
!
Call C_F_String( Temp_cPtr, FString255Path(1:n) )
!
End if
!
!
FString255 = FString255Path(1:n)//"\Icons\Icon_Charts.png"
IconImage_Ptr(j) = gtk_image_new_from_file( Trim(FString255)//c_Null_Char )
或将“\ Icons”设置为var并在开始时调整路径变量,例如
FString255Path = FString255Path(1:n)//"\Icons\"
FString255 = Trim(FString255Path)//"Icon_Charts.png"
...是的,我们也可以使用Allocatable字符串,这就是我们在这里使用固定len字符串的原因。
在这种情况下,通常的“简单”事实确实起作用,例如,正如最初想的那样,所需的相对路径方法确实如此:
FString255 = ".\Icons\Icon_Charts.png"
IconImage_Ptr(j) = gtk_image_new_from_file( Trim(FString255)//c_Null_Char )
好的,现在是“实际答案”,还有我们的“愚蠢纪念碑”;实际上这个Gtk应用程序非常庞大,前端的某些部分是用Glade和“builder”创建的,而其他部分则是用代码显式编写的。 Glade / builder位以及显式代码位都使用了一些相同的图标。碰巧的是,我们在开始时使用了正确的(相对)路径...不幸的是,我们在Glade / builder位生成的GUI的一部分中查找结果,当然它们有自己独立的加载图标的机制(即使在“代码”中重复使用相同的图标),因此没有任何摆弄“代码/路径”会产生任何差异。
......这对我们来说是一个“灌木联盟”的错误,如果整个问题/帖子被删除会感觉更好......但也许我们应该“尊重我们对愚蠢的纪念碑”:-)。
...我们为浪费任何人的时间道歉。