I used the following code to add a journal article (liferay 6.1):
JournalArticle ja = JournalArticleLocalServiceUtil.addArticle(
userId, groupId, 0, 0, StringPool.BLANK, true,
JournalArticleConstants.VERSION_DEFAULT, titleMap, descriptionMap,
content, "general", structureId, templateId, StringPool.BLANK,
1, 1, 2008, 0, 0, 0, 0, 0, 0, 0, true, 0, 0, 0, 0, 0, true,
true, false, StringPool.BLANK, null, null, StringPool.BLANK,
serviceContext);
For simplicity, I omitted some parts of the code. As specified in the parameters, smallImage = false. However, when adding new journal article, in the journalarticle table, the column SmallImageId always added a number which I was expecting as 0. Does anyone have experience on that?
Reaseon eludes me, but this behaviour is as expected (as programmed) because of this part of JournalArticleLocalServiceUtil.addArticle method
article.setSmallImage(smallImage);
article.setSmallImageId(counterLocalService.increment());
article.setSmallImageURL(smallImageURL);
only later in method is
saveImages(smallImage, article.getSmallImageId(), smallImageFile, smallImageBytes);
which is only part that checks smallImage boolean parameter
protected void saveImages(
boolean smallImage, long smallImageId, File smallImageFile,
byte[] smallImageBytes)
throws PortalException, SystemException {
if (smallImage) {
if ((smallImageFile != null) && (smallImageBytes != null)) {
imageLocalService.updateImage(smallImageId, smallImageBytes);
}
}
else {
imageLocalService.deleteImage(smallImageId);
}
}
Funny part is that workflow for new article without small image is as follows (only relevant parts):
create new article
save image (which you do not want) which actualy tries to remove image that you do not have
Related
I built a register model of UVM.
I connected the model to the environment, But the reset values in the registers aren't affected.
i'm adding a link to the code in EDA playground
Here the code of one of the registers: I set the configation with has_reset param and initialized the values of the register but it didn't affect the values.
class ctrl_p2_reg extends uvm_reg;
`uvm_object_utils(ctrl_p2_reg)
rand uvm_reg_field EN_PORT;
rand uvm_reg_field CLIMIT;
rand uvm_reg_field VLIMIT;
rand uvm_reg_field unused;
function new (string name = "ctrl_p2_reg");
super.new (name,8, UVM_NO_COVERAGE);
endfunction
virtual function void build ();
EN_PORT = uvm_reg_field::type_id::create ("EN_PORT");
CLIMIT = uvm_reg_field::type_id::create ("CLIMIT");
VLIMIT = uvm_reg_field::type_id::create ("VLIMIT");
unused = uvm_reg_field::type_id::create ("unused");
// configure(parent, size, lsb_pos, access, volatile, reset,
has_reset, is_rand, individually_accessible);
EN_PORT.configure (this, 1, 0, "RW", 0, 1'b1, 1, 1, 0);
LIMIT.configure (this, 2, 1, "RW", 0, 2'b11, 1, 1, 0);
VLIMIT.configure (this,2, 3, "RW", 0, 2'b11, 1, 1, 0);
unused.configure (this,3, 5, "RW", 0, 3'b111, 1, 1, 0);
endfunction:build
endclass:ctrl_p2_reg
I checked by sending a sequence that the register is indeed connected and it went fine. So I think the problem is probably just in the reset values.
I am trying to retrieve data from my smartsheet using SmartsheetClient. But when I try to access comments against a row, the comments are null. Following is my code:
string accessToken = "accesstokenvalue";
long sheetId = 121212221;
SmartsheetClient smartSheetClient = new SmartsheetBuilder().SetAccessToken(accessToken).Build();
IEnumerable<SheetLevelInclusion> inclusion = new SheetLevelInclusion[] { SheetLevelInclusion.ATTACHMENTS, SheetLevelInclusion.COLUMN_TYPE, SheetLevelInclusion.OBJECT_VALUE, SheetLevelInclusion.ROW_WRITER_INFO, SheetLevelInclusion.CONTACT_REFERENCES, SheetLevelInclusion.CROSS_SHEET_REFERENCES, SheetLevelInclusion.DISCUSSIONS, SheetLevelInclusion.FILTERS, SheetLevelInclusion.FILTER_DEFINITIONS, SheetLevelInclusion.FORMAT, SheetLevelInclusion.OWNER_INFO, SheetLevelInclusion.ROW_PERMALINK, SheetLevelInclusion.ROW_WRITER_INFO, SheetLevelInclusion.SOURCE };
Sheet sheet = smartSheetClient.SheetResources.GetSheet(sheetId, inclusion, null, null, null, null, null, null);
Reference Image:
Thanks
I could be wrong but I believe you'll have to list discussions on the row for that:
PaginatedResult<Discussion> discussions = smartsheet.SheetResources.RowResources.DiscussionResources.ListDiscussions(sheetId, sheet1.Rows[0].Id.Value, new DiscussionInclusion[] { DiscussionInclusion.COMMENTS }, null);
Can someone explain WaitNamedPipe for me? Using the examples on MSDN and elsewhere it doesn't seem to be as suggested. Using it in a different order does work.
In the examples, the client does
CreateFile (Pipe)
WaitNamedPipe
WriteFile
(Flushbuffers, CloseHandle)
Now for me, WaitNamedFile always times out unless I
WaitNamedFile
CreateFile
WriteFile
(Flushbuffers, CloseHandle)
Server -
hPipe = CreateNamedPipe(TEXT(HELPPIPE),
PIPE_ACCESS_INBOUND,
PIPE_TYPE_BYTE | PIPE_READMODE_BYTE | PIPE_WAIT,
1,
PIPEBUFFERSIZE,
PIPEBUFFERSIZE,
NMPWAIT_USE_DEFAULT_WAIT,
NULL);
and
while (!g_Quit)
{
if (ConnectNamedPipe(hPipe, NULL)) // wait for someone to connect to the pipe
{
char buffer[PIPEBUFFERSIZE];
DWORD dwRead;
while (ReadFile(hPipe, buffer, sizeof(buffer) - 1, &dwRead, NULL))
{
// add terminating zero
buffer[dwRead] = '\0';
if (!processHelpCommand(buffer))
{
g_Quit = true;
}
}
}
DisconnectNamedPipe(hPipe);
}
Client -
if (WaitNamedPipe (TEXT(HELPPIPE), 2000))
{
hPipe = CreateFile(TEXT(HELPPIPE),
GENERIC_WRITE,
0,
NULL,
OPEN_EXISTING,
0,
NULL);
if (hPipe != INVALID_HANDLE_VALUE)
{
if (WriteFile(hPipe,
commandLine,
strlen (commandLine) + 1,
&dwWritten,
NULL))
{
success = TRUE;
}
}
FlushFileBuffers(hPipe);
CloseHandle(hPipe);
}
The MSDN example is here
A few other on stackoverflow and elsewhere
Or is it that I've misunderstood the MSDN exmaple ;-)
I think I've answered my own question.
I'm trying to mimic some production code to generate Tiffs with a subject for testing purposes (IE in windows, right click, go to properties and the details tab there is a subject). We place some text we need to reference later in the subject field. The field we use is 0x9c9f which as far as I can find is (Subject tag used by Windows, encoded in UCS2)
Here's the code I'm using to generate the tag
public static void TagExtender(Tiff tif)
{
TiffFieldInfo[] tiffFieldInfo =
{
new TiffFieldInfo(TIFFTAG_SUBJECT, 256, 256, TiffType.BYTE, FieldBit.Custom, true, false, "XPSubject"),
};
tif.MergeFieldInfo(tiffFieldInfo, tiffFieldInfo.Length);
//if (m_parentExtender != null)
// m_parentExtender(tif);
}
public static void GenerateTiff(string filename, int pages = 1, bool encrypt = false, string tag = null)
{
// Register the custom tag handler
if (m_parentExtender == null)
{
Tiff.TiffExtendProc extender = TagExtender;
m_parentExtender = Tiff.SetTagExtender(extender);
}
// Open the output image
using (Tiff output = Tiff.Open(filename, "w"))
{
//...other code to generate tiff
if (tag != null)
{
byte[] bytes = UnicodeStr2HexStr(tag);
output.SetField(TIFFTAG_SUBJECT, bytes.Length-1, bytes);
}
// Code to actually write the image ....
output.WriteDirectory();
}
output.Close();
}
Basically, the tag (code wise) appears to be in the tiff but the windows properties dialog never shows it. Anything special needed to get this in place?
You are passing a bytecount, but set the passCount flag to false.
If you want to pass the count, use these lines at their correct positions:
// Your FieldInfo
new TiffFieldInfo((TiffTag)40095, -1, -1, TiffType.BYTE, FieldBit.Custom, true, true, "XPSubject")
// Your Input
byte[] test = Encoding.Unicode.GetBytes("Test3");
tiff.SetField((TiffTag)40095, test.Length, test);
I am in the process of building a temporal expression library that must be properly globalized and therefore work in all available Time Zones.
Now I seem to be stuck as I'm not sure how to retrieve adjusted dates from DateTimeOffset objects in the correct Daylight Savings Time (DST) when the transition boundary is crossed using any variety of .Add to move days, hours, etc.
Interestingly, I figured out a work around for the local system's Time Zone but haven't found any way to apply the same strategy to any arbitrary Time Zone.
I was able to find a snippet (didn't keep source, sorry!) which tries to reverse lookup the Time Zone Info by offset but as there are multiple potential results, each of which likely have different DST rules that will not work. (There may be some optimizations available but the base premis is flawed I think)
public TimeZoneInfo GetTimeZoneInfo(DateTimeOffset Value)
{
// Search available sytem time zones for a matching one
foreach (var tzi in TimeZoneInfo.GetSystemTimeZones())
{
// Compare value offset with time zone offset
if (tzi.GetUtcOffset(Value).Equals(Value.Offset))
{
return tzi;
}
}
}
This stuff can be a bit tedious to prove out so I've extracted the core issue into a couple methods and unit tests which will hopefully demonstrate the issue I'm facing.
public DateTimeOffset GetNextDay_Wrong(DateTimeOffset FromDateTimeOffset)
{
// Cannot create a new DateTimeOffset using simply the supplied value's UtcOffset
// because in PST, for example, it could be -7 or -8 depending on DST
return new DateTimeOffset(FromDateTimeOffset.Date.AddDays(1), FromDateTimeOffset.Offset);
}
[TestMethod]
public void GetNextDay_WrongTest()
{
var tz = TimeZoneInfo.FindSystemTimeZoneById("Pacific Standard Time");
var workingDate = new DateTime(2009, 11, 2, 0, 0, 0);
var failingDate = new DateTime(2009, 11, 1, 0, 0, 0);
var workingDate_tz = new DateTimeOffset(workingDate, tz.GetUtcOffset(workingDate));
var failingDate_tz = new DateTimeOffset(failingDate, tz.GetUtcOffset(failingDate));
var actual_workingDate_tz = GetNextDay_Wrong(workingDate_tz);
var actual_failingDate_tz = GetNextDay_Wrong(failingDate_tz);
var expected_workingDate = new DateTime(2009, 11, 3, 0, 0, 0);
var expected_failingDate = new DateTime(2009, 11, 2, 0, 0, 0);
var expected_workingDate_tz = new DateTimeOffset(expected_workingDate, tz.GetUtcOffset(expected_workingDate));
var expected_failingDate_tz = new DateTimeOffset(expected_failingDate, tz.GetUtcOffset(expected_failingDate));
Assert.AreEqual(expected_workingDate_tz, actual_workingDate_tz, "Should have found the following day's midnight");
Assert.AreEqual(expected_failingDate_tz, actual_failingDate_tz, "Failing date does not have the correct offset for it's DST");
}
public DateTimeOffset GetNextDay_LooksRight(DateTimeOffset FromDateTimeOffset)
{
// Because we cannot create a new DateTimeOffset we simply adjust the one provided!
var temp = FromDateTimeOffset;
// Move back to midnight of the current day
temp = temp.Subtract(new TimeSpan(temp.Hour, temp.Minute, temp.Second));
// Now move to the next day
temp = temp.AddDays(1);
// Let the DateTimeOffset class do it's magic
temp = temp.ToLocalTime();
// Check if the time zone has changed
if (FromDateTimeOffset.Offset != temp.Offset)
{
// Calculate the change amount (could be 30 mins or even stranger)
var delta = FromDateTimeOffset.Offset - temp.Offset;
// Adjust the temp value by the delta
temp = temp.Add(delta);
}
return temp.ToLocalTime();
}
[TestMethod]
public void GetNextDay_LooksRightTest()
{
// Everything is looking good and the test passes now, so we're home free yeah?
// { To work this needs to match your system's configured Local Time Zone, I'm in PST }
var tz = TimeZoneInfo.FindSystemTimeZoneById("Pacific Standard Time");
var workingDate = new DateTime(2009, 11, 2, 0, 0, 0);
var failingDate = new DateTime(2009, 11, 1, 0, 0, 0);
var workingDate_tz = new DateTimeOffset(workingDate, tz.GetUtcOffset(workingDate));
var failingDate_tz = new DateTimeOffset(failingDate, tz.GetUtcOffset(failingDate));
var actual_workingDate_tz = GetNextDay_LooksRight(workingDate_tz);
var actual_failingDate_tz = GetNextDay_LooksRight(failingDate_tz);
var expected_workingDate = new DateTime(2009, 11, 3, 0, 0, 0);
var expected_failingDate = new DateTime(2009, 11, 2, 0, 0, 0);
var expected_workingDate_tz = new DateTimeOffset(expected_workingDate, tz.GetUtcOffset(expected_workingDate));
var expected_failingDate_tz = new DateTimeOffset(expected_failingDate, tz.GetUtcOffset(expected_failingDate));
Assert.AreEqual(expected_workingDate_tz, actual_workingDate_tz, "Should have found the following day's midnight");
Assert.AreEqual(expected_failingDate_tz, actual_failingDate_tz, "Failing date does not have the correct offset for it's DST");
}
[TestMethod]
public void GetNextDay_LooksRight_FAILTest()
{
// Here is where the frustrating part is... aparantly the "magic" that DateTimeOffset provides only works for your systems Local Time Zone...
// { To properly fail this cannot match your system's configured Local Time Zone, I'm in PST so I use EST }
var tz = TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time");
var workingDate = new DateTime(2009, 11, 2, 0, 0, 0);
var failingDate = new DateTime(2009, 11, 1, 0, 0, 0);
var workingDate_tz = new DateTimeOffset(workingDate, tz.GetUtcOffset(workingDate));
var failingDate_tz = new DateTimeOffset(failingDate, tz.GetUtcOffset(failingDate));
var actual_workingDate_tz = GetNextDay_LooksRight(workingDate_tz);
var actual_failingDate_tz = GetNextDay_LooksRight(failingDate_tz);
var expected_workingDate = new DateTime(2009, 11, 3, 0, 0, 0);
var expected_failingDate = new DateTime(2009, 11, 2, 0, 0, 0);
var expected_workingDate_tz = new DateTimeOffset(expected_workingDate, tz.GetUtcOffset(expected_workingDate));
var expected_failingDate_tz = new DateTimeOffset(expected_failingDate, tz.GetUtcOffset(expected_failingDate));
Assert.AreEqual(expected_workingDate_tz, actual_workingDate_tz, "Should have found the following day's midnight");
Assert.AreEqual(expected_failingDate_tz, actual_failingDate_tz, "Failing date does not have the correct offset for it's DST");
}
The underlying issue with this case is that there is not enough information to perform the appropriate Time Zone conversions. Simple offset is not specific enough to infer the Time Zone because for a given offset at a specific moment there can be multiple potential Time Zones. Because the DateTimeOffset object does not capture and maintain the information about the Time Zone it was created with it must be the responsibility of something external to that class to maintain this relationship.
The thing that threw me off the scent was the call ToLocalTime() which I later realized was in fact introducing an implied TimeZoneInfo into the calculation, that of the configured local time for the machine and I believe that internally the DateTimeOffset must be converting to UTC by simply removing the configured offset and then creating a new DateTimeOffset class using the constructor taking DateTime [in UTC] and TimeZoneInfo [from local system] to produce the correct dst aware resulting date.
Given this limitation I no longer see any value in the DateTimeOffset class over the equally accurate and more valuable combination of DateTime and TimeZoneInfo.